Re: [PATCH] vme: add missing put_device() after device_register() fails
On 13/02/13 18:47, Emilio G. Cota wrote:
> From: "Emilio G. Cota"
>
> put_device() must be called after device_register() fails,
> since device_register() always initializes the refcount
> on the device structure.
>
> Signed-off-by: Emilio G. Cota
> ---
> drivers/vme/vme.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/vme/vme.c b/drivers/vme/vme.c
> index 95a9f71..5e6c7d7 100644
> --- a/drivers/vme/vme.c
> +++ b/drivers/vme/vme.c
> @@ -1366,26 +1366,27 @@ static int __vme_register_driver_bus(struct
> vme_driver *drv,
> err = device_register(&vdev->dev);
> if (err)
> goto err_reg;
>
> if (vdev->dev.platform_data) {
> list_add_tail(&vdev->drv_list, &drv->devices);
> list_add_tail(&vdev->bridge_list, &bridge->devices);
> } else
> device_unregister(&vdev->dev);
> }
> return 0;
>
> err_reg:
> + put_device(&vdev->dev);
> kfree(vdev);
> err_devalloc:
> list_for_each_entry_safe(vdev, tmp, &drv->devices, drv_list) {
> list_del(&vdev->drv_list);
> list_del(&vdev->bridge_list);
> device_unregister(&vdev->dev);
> }
> return err;
> }
Acked-by: Martyn Welch
(Sorry it took me so long to respond)
>
> static int __vme_register_driver(struct vme_driver *drv, unsigned int ndevs)
> {
> struct vme_bridge *bridge;
>
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
T +44(0)1327322748 | Manchester, M2 3AB
E martyn.we...@ge.com | VAT:GB 927559189
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vme: vme_tsi148.c: use module_pci_driver to simplify the code
On 18/10/2012 16:12, Wei Yongjun wrote:
From: Wei Yongjun
Use the module_pci_driver() macro to make the code simpler
by eliminating module_init and module_exit calls.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun
Huh, learn something new every day :-)
Acked-by: Martyn Welch
Thanks,
Martyn
---
drivers/vme/bridges/vme_tsi148.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/vme/bridges/vme_tsi148.c b/drivers/vme/bridges/vme_tsi148.c
index 5fbd08f..9c1aa4d 100644
--- a/drivers/vme/bridges/vme_tsi148.c
+++ b/drivers/vme/bridges/vme_tsi148.c
@@ -35,10 +35,8 @@
#include "../vme_bridge.h"
#include "vme_tsi148.h"
-static int __init tsi148_init(void);
static int tsi148_probe(struct pci_dev *, const struct pci_device_id *);
static void tsi148_remove(struct pci_dev *);
-static void __exit tsi148_exit(void);
/* Module parameter */
@@ -2244,11 +2242,6 @@ static void tsi148_free_consistent(struct device
*parent, size_t size,
pci_free_consistent(pdev, size, vaddr, dma);
}
-static int __init tsi148_init(void)
-{
- return pci_register_driver(&tsi148_driver);
-}
-
/*
* Configure CR/CSR space
*
@@ -2754,10 +2747,7 @@ static void tsi148_remove(struct pci_dev *pdev)
kfree(tsi148_bridge);
}
-static void __exit tsi148_exit(void)
-{
- pci_unregister_driver(&tsi148_driver);
-}
+module_pci_driver(tsi148_driver);
MODULE_PARM_DESC(err_chk, "Check for VME errors on reads and writes");
module_param(err_chk, bool, 0);
@@ -2767,6 +2757,3 @@ module_param(geoid, int, 0);
MODULE_DESCRIPTION("VME driver for the Tundra Tempe VME bridge");
MODULE_LICENSE("GPL");
-
-module_init(tsi148_init);
-module_exit(tsi148_exit);
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
T +44(0)1327322748 | Manchester, M2 3AB
E martyn.we...@ge.com | VAT:GB 927559189
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vme: vme_ca91cx42.c: use module_pci_driver to simplify the code
On 18/10/2012 16:13, Wei Yongjun wrote:
From: Wei Yongjun
Use the module_pci_driver() macro to make the code simpler
by eliminating module_init and module_exit calls.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun
Acked-by: Martyn Welch
---
drivers/vme/bridges/vme_ca91cx42.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/vme/bridges/vme_ca91cx42.c
b/drivers/vme/bridges/vme_ca91cx42.c
index 1425d22c..64bfea3 100644
--- a/drivers/vme/bridges/vme_ca91cx42.c
+++ b/drivers/vme/bridges/vme_ca91cx42.c
@@ -34,10 +34,8 @@
#include "../vme_bridge.h"
#include "vme_ca91cx42.h"
-static int __init ca91cx42_init(void);
static int ca91cx42_probe(struct pci_dev *, const struct pci_device_id *);
static void ca91cx42_remove(struct pci_dev *);
-static void __exit ca91cx42_exit(void);
/* Module parameters */
static int geoid;
@@ -1523,11 +1521,6 @@ static void ca91cx42_free_consistent(struct device
*parent, size_t size,
pci_free_consistent(pdev, size, vaddr, dma);
}
-static int __init ca91cx42_init(void)
-{
- return pci_register_driver(&ca91cx42_driver);
-}
-
/*
* Configure CR/CSR space
*
@@ -1944,16 +1937,10 @@ static void ca91cx42_remove(struct pci_dev *pdev)
kfree(ca91cx42_bridge);
}
-static void __exit ca91cx42_exit(void)
-{
- pci_unregister_driver(&ca91cx42_driver);
-}
+module_pci_driver(ca91cx42_driver);
MODULE_PARM_DESC(geoid, "Override geographical addressing");
module_param(geoid, int, 0);
MODULE_DESCRIPTION("VME driver for the Tundra Universe II VME bridge");
MODULE_LICENSE("GPL");
-
-module_init(ca91cx42_init);
-module_exit(ca91cx42_exit);
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
T +44(0)1327322748 | Manchester, M2 3AB
E martyn.we...@ge.com | VAT:GB 927559189
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vme: vme_vmivme7805.c: use module_pci_driver to simplify the code
On 18/10/2012 16:15, Wei Yongjun wrote:
From: Wei Yongjun
Use the module_pci_driver() macro to make the code simpler
by eliminating module_init and module_exit calls.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun
Acked-by: Martyn Welch
---
drivers/vme/boards/vme_vmivme7805.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/vme/boards/vme_vmivme7805.c
b/drivers/vme/boards/vme_vmivme7805.c
index 8e05bb4..dd22b50 100644
--- a/drivers/vme/boards/vme_vmivme7805.c
+++ b/drivers/vme/boards/vme_vmivme7805.c
@@ -19,10 +19,8 @@
#include "vme_vmivme7805.h"
-static int __init vmic_init(void);
static int vmic_probe(struct pci_dev *, const struct pci_device_id *);
static void vmic_remove(struct pci_dev *);
-static void __exit vmic_exit(void);
/** Base address to access FPGA register */
static void *vmic_base;
@@ -41,11 +39,6 @@ static struct pci_driver vmic_driver = {
.remove = vmic_remove,
};
-static int __init vmic_init(void)
-{
- return pci_register_driver(&vmic_driver);
-}
-
static int vmic_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
int retval;
@@ -109,15 +102,9 @@ static void vmic_remove(struct pci_dev *pdev)
}
-static void __exit vmic_exit(void)
-{
- pci_unregister_driver(&vmic_driver);
-}
+module_pci_driver(vmic_driver);
MODULE_DESCRIPTION("VMIVME-7805 board support driver");
MODULE_AUTHOR("Arthur Benilov ");
MODULE_LICENSE("GPL");
-module_init(vmic_init);
-module_exit(vmic_exit);
-
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
T +44(0)1327322748 | Manchester, M2 3AB
E martyn.we...@ge.com | VAT:GB 927559189
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vme: vme_tsi148.c: fix error return code in tsi148_probe()
On 19/06/13 03:42, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Fix to return a negative error code in the tsi148_crcsr_init() error
> handling case instead of 0, as done elsewhere in this function.
>
Hi Wei,
Thanks for your patch looks good.
Signed-off-by: Martyn Welch
> Signed-off-by: Wei Yongjun
> ---
> drivers/vme/bridges/vme_tsi148.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/vme/bridges/vme_tsi148.c
> b/drivers/vme/bridges/vme_tsi148.c
> index 9c1aa4d..95c9b54 100644
> --- a/drivers/vme/bridges/vme_tsi148.c
> +++ b/drivers/vme/bridges/vme_tsi148.c
> @@ -2582,7 +2582,8 @@ static int tsi148_probe(struct pci_dev *pdev, const
> struct pci_device_id *id)
> dev_info(&pdev->dev, "VME Write and flush and error check is %s\n",
> err_chk ? "enabled" : "disabled");
>
> - if (tsi148_crcsr_init(tsi148_bridge, pdev)) {
> + retval = tsi148_crcsr_init(tsi148_bridge, pdev);
> + if (retval) {
> dev_err(&pdev->dev, "CR/CSR configuration failed.\n");
> goto err_crcsr;
> }
>
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
T +44(0)1327322748 | Manchester, M2 3AB
E martyn.we...@ge.com | VAT:GB 927559189
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: vme: fix for a potential NULL pointer dereference
On 25/03/13 05:37, Kumar Amit Mehta wrote:
> Audit the return value of cdev_alloc and hence fixes a potential NULL pointer
> dereferencing.
>
> Signed-off-by: Kumar Amit Mehta
Looks good to me, thanks.
Signed-off-by: Martyn Welch
> ---
> drivers/staging/vme/devices/vme_user.c |4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/staging/vme/devices/vme_user.c
> b/drivers/staging/vme/devices/vme_user.c
> index d074b1e..da7f759 100644
> --- a/drivers/staging/vme/devices/vme_user.c
> +++ b/drivers/staging/vme/devices/vme_user.c
> @@ -710,6 +710,10 @@ static int vme_user_probe(struct vme_dev *vdev)
>
> /* Register the driver as a char device */
> vme_user_cdev = cdev_alloc();
> + if (!vme_user_cdev) {
> + err = -ENOMEM;
> + goto err_char;
> + }
> vme_user_cdev->ops = &vme_user_fops;
> vme_user_cdev->owner = THIS_MODULE;
> err = cdev_add(vme_user_cdev, MKDEV(VME_MAJOR, 0), VME_DEVS);
>
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
T +44(0)1327322748 | Manchester, M2 3AB
E martyn.we...@ge.com | VAT:GB 927559189
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: vme: fix error return code in vme_user_probe()
On 13/05/13 07:05, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Fix to return -ENOMEM in the resource alloc error handling
> case instead of 0, as done elsewhere in this function.
>
Hi Wei,
Thanks for your patch. As this is resource allocation rather than memory
allocation that is failing, would -EAGAIN not make more sense than -ENOMEM?
Martyn
> Signed-off-by: Wei Yongjun
> ---
> drivers/staging/vme/devices/vme_user.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/staging/vme/devices/vme_user.c
> b/drivers/staging/vme/devices/vme_user.c
> index da7f759..5fe224d3 100644
> --- a/drivers/staging/vme/devices/vme_user.c
> +++ b/drivers/staging/vme/devices/vme_user.c
> @@ -734,6 +734,7 @@ static int vme_user_probe(struct vme_dev *vdev)
> if (image[i].resource == NULL) {
> dev_warn(&vdev->dev,
>"Unable to allocate slave resource\n");
> + err = -ENOMEM;
> goto err_slave;
> }
> image[i].size_buf = PCI_BUF_SIZE;
> @@ -760,6 +761,7 @@ static int vme_user_probe(struct vme_dev *vdev)
> if (image[i].resource == NULL) {
> dev_warn(&vdev->dev,
>"Unable to allocate master resource\n");
> + err = -ENOMEM;
> goto err_master;
> }
> image[i].size_buf = PCI_BUF_SIZE;
>
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
T +44(0)1327322748 | Manchester, M2 3AB
E martyn.we...@ge.com | VAT:GB 927559189
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: vme: fix error return code in vme_user_probe()
On 13/05/13 09:51, Dan Carpenter wrote: > On Mon, May 13, 2013 at 09:16:00AM +0100, Martyn Welch wrote: >> On 13/05/13 07:05, Wei Yongjun wrote: >>> From: Wei Yongjun >>> >>> Fix to return -ENOMEM in the resource alloc error handling >>> case instead of 0, as done elsewhere in this function. >>> >> >> Hi Wei, >> >> Thanks for your patch. As this is resource allocation rather than memory >> allocation that is failing, would -EAGAIN not make more sense than -ENOMEM? >> > > ENOMEM is better. EAGAIN is for when trylock() fails etc. In other > words we are not allowed to block and someone is using the lock we > need. > ENOMEM just doesn't seem to describe the error very well. This error will be triggered if no free VME windows are available for the driver to use - there are typically 8 master and 8 slave windows provided in hardware. How about EBUSY (Device or resource busy)? > It feels like we discuss error codes a lot on LKML and they should > be documented under Documententation/. The closest thing is > Documentation/i2c/fault-codes. > I'd been looking at the errno man page since I was under the impression that these values would typically find their way back to user space. Martyn -- Martyn Welch (Lead Software Engineer) | Registered in England and Wales GE Intelligent Platforms | (3828642) at 100 Barbirolli Square T +44(0)1327322748 | Manchester, M2 3AB E martyn.we...@ge.com | VAT:GB 927559189 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: vme: fix error return code in vme_user_probe()
On 14/05/13 15:19, Dan Carpenter wrote: > On Tue, May 14, 2013 at 02:56:17PM +0100, Martyn Welch wrote: >> On 13/05/13 09:51, Dan Carpenter wrote: >>> On Mon, May 13, 2013 at 09:16:00AM +0100, Martyn Welch wrote: >>>> On 13/05/13 07:05, Wei Yongjun wrote: >>>>> From: Wei Yongjun >>>>> >>>>> Fix to return -ENOMEM in the resource alloc error handling >>>>> case instead of 0, as done elsewhere in this function. >>>>> >>>> >>>> Hi Wei, >>>> >>>> Thanks for your patch. As this is resource allocation rather than memory >>>> allocation that is failing, would -EAGAIN not make more sense than -ENOMEM? >>>> >>> >>> ENOMEM is better. EAGAIN is for when trylock() fails etc. In other >>> words we are not allowed to block and someone is using the lock we >>> need. >>> >> >> ENOMEM just doesn't seem to describe the error very well. This error will be >> triggered if no free VME windows are available for the driver to use - there >> are typically 8 master and 8 slave windows provided in hardware. >> >> How about EBUSY (Device or resource busy)? > > EBUSY would work. > Hi Wei, Would you mind resubmitting your patch returning the error code EBUSY rather than ENOMEM? Martyn -- Martyn Welch (Lead Software Engineer) | Registered in England and Wales GE Intelligent Platforms | (3828642) at 100 Barbirolli Square T +44(0)1327322748 | Manchester, M2 3AB E martyn.we...@ge.com | VAT:GB 927559189 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]staging "vme" Fix typos.
On 13/08/12 16:58, Justin P. Mattock wrote: > From: "Justin P. Mattock" > > Signed-off-by: Justin P. Mattock > > --- > > The below patch fixes typos found while reading through staging "vme" > > drivers/staging/vme/devices/Kconfig|2 +- > drivers/staging/vme/devices/vme_user.c |6 +++--- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/staging/vme/devices/Kconfig > b/drivers/staging/vme/devices/Kconfig > index d0cab17..5504ab4 100644 > --- a/drivers/staging/vme/devices/Kconfig > +++ b/drivers/staging/vme/devices/Kconfig > @@ -5,7 +5,7 @@ config VME_USER > depends on STAGING > help > If you say Y here you want to be able to access a limited number of > - VME windows in a manner at least semi-compatible with the interface > + VME windows in a manner atleast semi-compatible with the interface Um, are you sure? I don't think "atleast" is a word. > provided with the original driver at http://vmelinux.org/. > > config VME_PIO2 > diff --git a/drivers/staging/vme/devices/vme_user.c > b/drivers/staging/vme/devices/vme_user.c > index e25645e..46f60d6 100644 > --- a/drivers/staging/vme/devices/vme_user.c > +++ b/drivers/staging/vme/devices/vme_user.c > @@ -64,12 +64,12 @@ static unsigned int bus_num; > * > * However the VME driver at http://www.vmelinux.org/ is rather old and > doesn't > * even support the tsi148 chipset (which has 8 master and 8 slave windows). > - * We'll run with this or now as far as possible, however it probably makes > + * We'll run with this for now as far as possible, however it probably makes > * sense to get rid of the old mappings and just do everything dynamically. > * > * So for now, we'll restrict the driver to providing 4 masters and 4 slaves > as > * defined above and try to support at least some of the interface from > - * http://www.vmelinux.org/ as an alternative drive can be written providing > a > + * http://www.vmelinux.org/ as an alternative the driver can be written > providing a Sorry, but you'll have to wrap the line here. The comment now extends beyond 80 characters. > * saner interface later. > * > * The vmelinux.org driver never supported slave images, the devices reserved > @@ -242,7 +242,7 @@ static ssize_t resource_to_user(int minor, char __user > *buf, size_t count, > } > > /* > - * We are going ot alloc a page during init per window for small transfers. > + * We are going to alloc a page during init per window for small transfers. Yup - that's OK. Care to fix up the issues above? Martyn > * Small transfers will go user space -> buffer -> VME. Larger (more than a > * page) transfers will lock the user space buffer into memory and then > * transfer the data directly from the user space buffers out to VME. > -- Martyn Welch (Lead Software Engineer) | Registered in England and Wales GE Intelligent Platforms | (3828642) at 100 Barbirolli Square T +44(0)1327322748 | Manchester, M2 3AB E martyn.we...@ge.com | VAT:GB 927559189 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2]staging "vme" Fix typos.
On 13/08/12 18:28, Justin P. Mattock wrote: > From: "Justin P. Mattock" > > Signed-off-by: Justin P. Mattock > > --- > Note:resend with minor adjustments. > The below patch fixes typos found while reading through staging "vme" > > drivers/staging/vme/devices/vme_user.c |8 > 1 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/staging/vme/devices/vme_user.c > b/drivers/staging/vme/devices/vme_user.c > index e25645e..0170788 100644 > --- a/drivers/staging/vme/devices/vme_user.c > +++ b/drivers/staging/vme/devices/vme_user.c > @@ -64,13 +64,13 @@ static unsigned int bus_num; > * > * However the VME driver at http://www.vmelinux.org/ is rather old and > doesn't > * even support the tsi148 chipset (which has 8 master and 8 slave windows). > - * We'll run with this or now as far as possible, however it probably makes > + * We'll run with this for now as far as possible, however it probably makes > * sense to get rid of the old mappings and just do everything dynamically. > * > * So for now, we'll restrict the driver to providing 4 masters and 4 slaves > as > * defined above and try to support at least some of the interface from > - * http://www.vmelinux.org/ as an alternative drive can be written providing > a > - * saner interface later. > + * http://www.vmelinux.org/ as an alternative the driver can be written > + * providing a saner interface later. > * > * The vmelinux.org driver never supported slave images, the devices reserved > * for slaves were repurposed to support all 8 master images on the > UniverseII! > @@ -242,7 +242,7 @@ static ssize_t resource_to_user(int minor, char __user > *buf, size_t count, > } > > /* > - * We are going ot alloc a page during init per window for small transfers. > + * We are going to alloc a page during init per window for small transfers. > * Small transfers will go user space -> buffer -> VME. Larger (more than a > * page) transfers will lock the user space buffer into memory and then > * transfer the data directly from the user space buffers out to VME. > Thanks for updating the patch, that's much better: Acked-by: Martyn Welch -- Martyn Welch (Lead Software Engineer) | Registered in England and Wales GE Intelligent Platforms | (3828642) at 100 Barbirolli Square T +44(0)1327322748 | Manchester, M2 3AB E martyn.we...@ge.com | VAT:GB 927559189 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/12] staging: vme_pio2: fix oops on module unloading
On 14/12/12 11:02, Konstantin Khlebnikov wrote:
> This patch forbids loading vme_pio2 module without specifing "num_bus"
> parameter.
> Otherwise on module unloading pio2_exit() calls vme_unregister_driver() for
> not
> registered pio2_driver.
>
Acked-by: Martyn Welch
> Signed-off-by: Konstantin Khlebnikov
> Cc: Martyn Welch
> Cc: Manohar Vanga
> Cc: Greg Kroah-Hartman
> Cc: de...@driverdev.osuosl.org
> ---
> drivers/staging/vme/devices/vme_pio2_core.c | 14 ++
> 1 file changed, 2 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/staging/vme/devices/vme_pio2_core.c
> b/drivers/staging/vme/devices/vme_pio2_core.c
> index 0331178..bf73ba2 100644
> --- a/drivers/staging/vme/devices/vme_pio2_core.c
> +++ b/drivers/staging/vme/devices/vme_pio2_core.c
> @@ -162,11 +162,9 @@ static struct vme_driver pio2_driver = {
>
> static int __init pio2_init(void)
> {
> - int retval = 0;
> -
> if (bus_num == 0) {
> pr_err("No cards, skipping registration\n");
> - goto err_nocard;
> + return -ENODEV;
> }
>
> if (bus_num > PIO2_CARDS_MAX) {
> @@ -176,15 +174,7 @@ static int __init pio2_init(void)
> }
>
> /* Register the PIO2 driver */
> - retval = vme_register_driver(&pio2_driver, bus_num);
> - if (retval != 0)
> - goto err_reg;
> -
> - return retval;
> -
> -err_reg:
> -err_nocard:
> - return retval;
> + return vme_register_driver(&pio2_driver, bus_num);
> }
>
> static int pio2_match(struct vme_dev *vdev)
>
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
T +44(0)1327322748 | Manchester, M2 3AB
E martyn.we...@ge.com | VAT:GB 927559189
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
alloc_bootmem - Kernel panic
Hi Everyone,
First I'd like to appologise if my query is glaringly obvious. I'm
reasonable new to this, but every that I have read (including the Linux
Device Drivers book) seems to suggest that what I am doing should
work...
I am attempting to allocate a large buffer for DMA transfers in a driver
I am working on. I understand that the kernel normally will not allocate
block of coherent memory larger than 128KB, the suggested solution seems
to be to compile the driver into the kernel and allocate memory at boot
using alloc_bootmem. When attempting this I receive a kernel panic:
=
Loading driver.
bootmem alloc of 4096 bytes failed!
Kernel panic - not syncing: Out of memory
=
This is using:
kernel version 2.6.20
gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)
The config is based on the default i386 config + one extra option to
cause my driver to be compiled in.
The offending code is listed below,
Thank you for any help in advance,
Martyn
=
#include
#include
#include
#include
#include
void *buffer;
static int __init universeII_init(void)
{
printk(KERN_INFO "Loading driver.\n");
buffer = alloc_bootmem(PAGE_SIZE);
return 0;
}
static void __exit universeII_exit(void)
{
if (buffer != NULL) {
free_bootmem((unsigned long)buffer, PAGE_SIZE);
}
printk(KERN_INFO "Driver removed.\n");
}
MODULE_DESCRIPTION("alloc_bootmem_x Test");
MODULE_AUTHOR("Martyn Welch <[EMAIL PROTECTED]>");
MODULE_LICENSE("GPL");
/** Register initilisation function */
module_init(universeII_init);
/** Register cleanup function */
module_exit(universeII_exit);
This e-mail has been scanned for all viruses by Star.The service is powered by
MessageLabs.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: alloc_bootmem - Kernel panic
Hi Asgard, Thank you for your reply. > I don't sure, that linux performs to allocate bootmem after kernel already > booted. > As I know, bootmem allocator "destroyed" when kernel initializes buddy > allocator. > Indeed you can look at arch/i385/mm/init.c, mem_init routine. > kernel passes all bootmem pages to buddy system, so bootmem allocator can't > be used after it. That explains why I can't use alloc_bootmem. It'd assumed that do_initcalls and hence functions labelled with module_init() were called early enough, mainly because LDD3 suggests using alloc_bootmem. It seems the vt driver uses console_init() instead, which is called much earlier. Which leads me to the question: what is the best method to reserve a large (~4MB) coherent buffer for DMA transfers? Is there any way of using alloc_bootmem from a driver (compiled into the kernel) without delving further into kernel code? Martyn This e-mail has been scanned for all viruses by Star.The service is powered by MessageLabs. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vme: fake: mark symbols static where possible
On 23 September 2016 at 14:38, Baoyou Xie wrote:
> We get 4 warnings when building kernel with W=1:
> drivers/vme/bridges/vme_fake.c:384:6: warning: no previous prototype for
> 'fake_lm_check' [-Wmissing-prototypes]
> drivers/vme/bridges/vme_fake.c:619:6: warning: no previous prototype for
> 'fake_vmewrite8' [-Wmissing-prototypes]
> drivers/vme/bridges/vme_fake.c:649:6: warning: no previous prototype for
> 'fake_vmewrite16' [-Wmissing-prototypes]
> drivers/vme/bridges/vme_fake.c:679:6: warning: no previous prototype for
> 'fake_vmewrite32' [-Wmissing-prototypes]
>
> In fact, these functions are only used in the file in which they are
> declared and don't need a declaration, but can be made static.
> so this patch marks these functions with 'static'.
>
> Signed-off-by: Baoyou Xie
Acked-by: Martyn Welch
> ---
> drivers/vme/bridges/vme_fake.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/vme/bridges/vme_fake.c b/drivers/vme/bridges/vme_fake.c
> index ebf35d3..29ac74f 100644
> --- a/drivers/vme/bridges/vme_fake.c
> +++ b/drivers/vme/bridges/vme_fake.c
> @@ -381,8 +381,8 @@ static int fake_master_get(struct vme_master_resource
> *image, int *enabled,
> }
>
>
> -void fake_lm_check(struct fake_driver *bridge, unsigned long long addr,
> - u32 aspace, u32 cycle)
> +static void fake_lm_check(struct fake_driver *bridge, unsigned long long
> addr,
> + u32 aspace, u32 cycle)
> {
> struct vme_bridge *fake_bridge;
> unsigned long long lm_base;
> @@ -616,8 +616,8 @@ static ssize_t fake_master_read(struct
> vme_master_resource *image, void *buf,
> return retval;
> }
>
> -void fake_vmewrite8(struct fake_driver *bridge, u8 *buf,
> -unsigned long long addr, u32 aspace, u32 cycle)
> +static void fake_vmewrite8(struct fake_driver *bridge, u8 *buf,
> + unsigned long long addr, u32 aspace, u32 cycle)
> {
> int i;
> unsigned long long start, end, offset;
> @@ -646,8 +646,8 @@ void fake_vmewrite8(struct fake_driver *bridge, u8 *buf,
>
> }
>
> -void fake_vmewrite16(struct fake_driver *bridge, u16 *buf,
> - unsigned long long addr, u32 aspace, u32 cycle)
> +static void fake_vmewrite16(struct fake_driver *bridge, u16 *buf,
> + unsigned long long addr, u32 aspace, u32 cycle)
> {
> int i;
> unsigned long long start, end, offset;
> @@ -676,8 +676,8 @@ void fake_vmewrite16(struct fake_driver *bridge, u16 *buf,
>
> }
>
> -void fake_vmewrite32(struct fake_driver *bridge, u32 *buf,
> - unsigned long long addr, u32 aspace, u32 cycle)
> +static void fake_vmewrite32(struct fake_driver *bridge, u32 *buf,
> + unsigned long long addr, u32 aspace, u32 cycle)
> {
> int i;
> unsigned long long start, end, offset;
> --
> 2.7.4
>
Re: [PATCH v3] watchdog: ziirave_wdt: Add support to upload the firmware.
On 28/07/16 11:37, Enric Balletbo i Serra wrote:
This patch adds and entry to the sysfs to start firmware upload process
on the specified device with the requested firmware.
The uploading of the firmware needs only to happen once per firmware
upgrade, as the firmware is stored in persistent storage. If the
firmware upload or the firmware verification fails then we print and
error message and exit.
Signed-off-by: Enric Balletbo i Serra
---
Changes since v2: (requested by Guenter)
- Remove ihex parsing, convert the file into binary before passing it to the
kernel (ihex2fw ).
- New binary firmware parsed using the ihex.h helpers.
- Protect firmware upgrade with a mutex.
- Remove a noisy message.
- Remove some unneded memset.
- Remove some unnecessary ()
Changes since v1: (requested by Martyn)
- Remove two defines that are not used.
- Fix typo in documentation count -> length
drivers/watchdog/ziirave_wdt.c | 363 +
1 file changed, 363 insertions(+)
diff --git a/drivers/watchdog/ziirave_wdt.c b/drivers/watchdog/ziirave_wdt.c
index fa1efef..81c8545 100644
--- a/drivers/watchdog/ziirave_wdt.c
+++ b/drivers/watchdog/ziirave_wdt.c
@@ -18,7 +18,10 @@
* GNU General Public License for more details.
*/
+#include
#include
+#include
+#include
#include
#include
#include
@@ -36,6 +39,8 @@
#define ZIIRAVE_STATE_OFF 0x1
#define ZIIRAVE_STATE_ON 0x2
+#define ZIIRAVE_FW_NAME"ziirave_wdt.fw"
+
static char *ziirave_reasons[] = {"power cycle", "hw watchdog", NULL, NULL,
"host request", NULL, "illegal configuration",
"illegal instruction", "illegal trap",
@@ -50,12 +55,32 @@ static char *ziirave_reasons[] = {"power cycle", "hw
watchdog", NULL, NULL,
#define ZIIRAVE_WDT_PING 0x9
#define ZIIRAVE_WDT_RESET_DURATION0xa
+#define ZIIRAVE_FIRM_PKT_TOTAL_SIZE20
+#define ZIIRAVE_FIRM_PKT_DATA_SIZE 16
+#define ZIIRAVE_FIRM_FLASH_MEMORY_START0x1600
+#define ZIIRAVE_FIRM_FLASH_MEMORY_END 0x2bbf
+
+/* Received and ready for next Download packet. */
+#define ZIIRAVE_FIRM_DOWNLOAD_ACK 1
+/* Currently writing to flash. Retry Download status in a moment! */
+#define ZIIRAVE_FIRM_DOWNLOAD_BUSY 2
+
+/* Firmware commands */
+#define ZIIRAVE_CMD_DOWNLOAD_START 0x10
+#define ZIIRAVE_CMD_DOWNLOAD_END 0x11
+#define ZIIRAVE_CMD_DOWNLOAD_SET_READ_ADDR 0x12
+#define ZIIRAVE_CMD_DOWNLOAD_READ_BYTE 0x13
+#define ZIIRAVE_CMD_RESET_PROCESSOR0x0b
+#define ZIIRAVE_CMD_JUMP_TO_BOOTLOADER 0x0c
+#define ZIIRAVE_CMD_DOWNLOAD_PACKET0x0e
+
struct ziirave_wdt_rev {
unsigned char major;
unsigned char minor;
};
struct ziirave_wdt_data {
+ struct mutex sysfs_mutex;
I don't think this is the best name for the mutex given that it's only
used with firmware upload. "firmware_mutex"?ffir
struct watchdog_device wdd;
struct ziirave_wdt_rev bootloader_rev;
struct ziirave_wdt_rev firmware_rev;
@@ -146,6 +171,288 @@ static unsigned int ziirave_wdt_get_timeleft(struct
watchdog_device *wdd)
return ret;
}
+static int ziirave_firm_wait_for_ack(struct watchdog_device *wdd)
+{
+ struct i2c_client *client = to_i2c_client(wdd->parent);
+ int ret;
+
+ do {
+ usleep_range(5000, 5100);
+ ret = i2c_smbus_read_byte(client);
+ if (ret < 0) {
+ dev_err(&client->dev, "Failed to read byte\n");
+ return ret;
+ }
+ } while (ret == ZIIRAVE_FIRM_DOWNLOAD_BUSY);
+
+ return ret == ZIIRAVE_FIRM_DOWNLOAD_ACK ? 0 : -EIO;
+}
+
+static int ziirave_firm_set_read_addr(struct watchdog_device *wdd, u16 addr)
+{
+ struct i2c_client *client = to_i2c_client(wdd->parent);
+ u8 address[2];
+
+ address[0] = addr & 0xff;
+ address[1] = (addr >> 8) & 0xff;
+
+ return i2c_smbus_write_block_data(client,
+ ZIIRAVE_CMD_DOWNLOAD_SET_READ_ADDR,
+ ARRAY_SIZE(address), address);
+}
+
+static int ziirave_firm_write_block_data(struct watchdog_device *wdd,
+u8 command, u8 length, const u8 *data,
+bool wait_for_ack)
+{
+ struct i2c_client *client = to_i2c_client(wdd->parent);
+ int ret;
+
+ ret = i2c_smbus_write_block_data(client, command, length, data);
+
+ if (ret) {
+ dev_err(&client->dev,
+ "Failed to send command 0x%02x: %d\n", command, ret);
+ return ret;
+ }
+
+ if (wait_for_ack)
+ ret = ziirave_firm_wait_for_ack(wdd);
+
+ return ret;
+}
+
+static int ziirave_firm_write_byte(struct watchdog_device *wdd, u8 command,
+
Re: [PATCH] vme: fake: fix build for 64-bit dma_addr_t
On Tue, Sep 06, 2016 at 02:59:41PM +0200, Arnd Bergmann wrote:
> casting between dma_addr_t and a pointer is generally tricky,
> as they might not be the same size and almost never point into
> the same address space. With 32-bit ARM systems and LPAE, we
> get this warning for the vme_fake driver that stores a pointer
> in a dma_addr_t variable:
>
> drivers/vme/bridges/vme_fake.c: In function 'fake_slave_set':
> drivers/vme/bridges/vme_fake.c:204:29: error: assignment makes pointer from
> integer without a cast [-Werror=int-conversion]
>
> To make this clearer while fixing the warning, I'm adding
> a set of helper functions for the type conversion.
>
> Signed-off-by: Arnd Bergmann
Acked-by: Martyn Welch
> ---
> drivers/vme/bridges/vme_fake.c | 26 ++
> 1 file changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/vme/bridges/vme_fake.c b/drivers/vme/bridges/vme_fake.c
> index 7ef298b289f4..ebf35d305321 100644
> --- a/drivers/vme/bridges/vme_fake.c
> +++ b/drivers/vme/bridges/vme_fake.c
> @@ -48,7 +48,7 @@ struct fake_slave_window {
> int enabled;
> unsigned long long vme_base;
> unsigned long long size;
> - dma_addr_t buf_base;
> + void *buf_base;
> u32 aspace;
> u32 cycle;
> };
> @@ -114,6 +114,16 @@ static void fake_irq_set(struct vme_bridge *fake_bridge,
> int level,
> /* Nothing to do */
> }
>
> +static void *fake_pci_to_ptr(dma_addr_t addr)
> +{
> + return (void *)(uintptr_t)addr;
> +}
> +
> +static dma_addr_t fake_ptr_to_pci(void *addr)
> +{
> + return (dma_addr_t)(uintptr_t)addr;
> +}
> +
> /*
> * Generate a VME bus interrupt at the requested level & vector. Wait for
> * interrupt to be acked.
> @@ -202,7 +212,7 @@ static int fake_slave_set(struct vme_slave_resource
> *image, int enabled,
> bridge->slaves[i].enabled = enabled;
> bridge->slaves[i].vme_base = vme_base;
> bridge->slaves[i].size = size;
> - bridge->slaves[i].buf_base = buf_base;
> + bridge->slaves[i].buf_base = fake_pci_to_ptr(buf_base);
> bridge->slaves[i].aspace = aspace;
> bridge->slaves[i].cycle = cycle;
>
> @@ -230,7 +240,7 @@ static int fake_slave_get(struct vme_slave_resource
> *image, int *enabled,
> *enabled = bridge->slaves[i].enabled;
> *vme_base = bridge->slaves[i].vme_base;
> *size = bridge->slaves[i].size;
> - *buf_base = bridge->slaves[i].buf_base;
> + *buf_base = fake_ptr_to_pci(bridge->slaves[i].buf_base);
> *aspace = bridge->slaves[i].aspace;
> *cycle = bridge->slaves[i].cycle;
>
> @@ -431,7 +441,7 @@ static u8 fake_vmeread8(struct fake_driver *bridge,
> unsigned long long addr,
>
> if ((addr >= start) && (addr < end)) {
> offset = addr - bridge->slaves[i].vme_base;
> - loc = (u8 *)((void *)bridge->slaves[i].buf_base +
> offset);
> + loc = (u8 *)(bridge->slaves[i].buf_base + offset);
> retval = *loc;
>
> break;
> @@ -463,7 +473,7 @@ static u16 fake_vmeread16(struct fake_driver *bridge,
> unsigned long long addr,
>
> if ((addr >= start) && ((addr + 1) < end)) {
> offset = addr - bridge->slaves[i].vme_base;
> - loc = (u16 *)((void *)bridge->slaves[i].buf_base +
> offset);
> + loc = (u16 *)(bridge->slaves[i].buf_base + offset);
> retval = *loc;
>
> break;
> @@ -495,7 +505,7 @@ static u32 fake_vmeread32(struct fake_driver *bridge,
> unsigned long long addr,
>
> if ((addr >= start) && ((addr + 3) < end)) {
> offset = addr - bridge->slaves[i].vme_base;
> - loc = (u32 *)((void *)bridge->slaves[i].buf_base +
> offset);
> + loc = (u32 *)(bridge->slaves[i].buf_base + offset);
> retval = *loc;
>
> break;
> @@ -997,7 +1007,7 @@ static void *fake_alloc_consistent(struct device
> *parent, size_t size,
> void *alloc = kmalloc(size, GFP_KERNEL);
>
> if (alloc != NULL)
> - *dma = (dma_addr_t)(unsigned long)alloc;
> + *dma = fake_ptr_to_pci(alloc);
>
> return alloc;
> }
> @@ -1031,7 +1041,7 @@ static int fake_crcsr_init(struct vme_bridge
> *fake_bridge)
>
> /* Allocate mem for CR/CSR image */
> bridge->crcsr_kernel = kzalloc(VME_CRCSR_BUF_SIZE, GFP_KERNEL);
> - bridge->crcsr_bus = (dma_addr_t)bridge->crcsr_kernel;
> + bridge->crcsr_bus = fake_ptr_to_pci(bridge->crcsr_kernel);
> if (bridge->crcsr_kernel == NULL)
> return -ENOMEM;
>
> --
> 2.9.0
>
Re: [GIT PULL] VME Subsystem patches for 4.14-rc4
On Sat, 2017-10-14 at 14:08 +0200, Greg Kroah-Hartman wrote: > On Fri, Oct 13, 2017 at 10:09:19PM +0100, Martyn Welch wrote: > > The following changes since commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f: > > > > Linux 4.14-rc4 (2017-10-08 20:53:29 -0700) > > > > are available in the git repository at: > > > > https://gitlab.collabora.com/martyn/linux.git tags/vme-next-4.14-rc4 > > > > for you to fetch changes up to a75dc630086a6b83d780a7b27d03c4c0abdf0807: > > > > vme: tsi148: Adjust 14 checks for null pointers (2017-10-13 21:32:04 > > +0100) > > > > > > VME Subsystem changes for master v4.14-rc4: > > > > - Corrections across the VME subsystem to better align with the preferred > >kernel coding style. > > > > > > Markus Elfring (14): > > vme: Delete 11 error messages for a failed memory allocation > > vme: Improve 11 size determinations > > vme: Move an assignment in vme_new_dma_list() > > vme: Adjust 48 checks for null pointers > > vme: Return directly in two functions > > vme: fake: Delete an error message for a failed memory allocation in > > fake_init() > > vme: fake: Improve five size determinations in fake_init() > > vme: fake: Adjust 11 checks for null pointers > > vme: ca91cx42: Delete eight error messages for a failed memory > > allocation > > vme: ca91cx42: Improve 12 size determinations > > vme: ca91cx42: Adjust 14 checks for null pointers > > vme: tsi148: Delete nine error messages for a failed memory allocation > > vme: tsi148: Improve 17 size determinations > > vme: tsi148: Adjust 14 checks for null pointers > > > > drivers/vme/bridges/vme_ca91cx42.c | 73 +- > > drivers/vme/bridges/vme_fake.c | 35 +++ > > drivers/vme/bridges/vme_tsi148.c | 83 ++-- > > drivers/vme/vme.c | 194 > > - > > 4 files changed, 157 insertions(+), 228 deletions(-) > > None of these are bugfixes for 4.14-final, right? They should all be > delayed until 4.15-rc1? > Yeah, 4.15-rc1. Thanks Martyn > thanks, > > greg k-h > ___ > devel mailing list > de...@linuxdriverproject.org > http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] ahci: imx: Handle increased read failures for IMX53 temperature sensor in low frequency mode.
From: Egor Starkov
Extended testing has shown that the imx ahci driver sometimes requires
more than the 100 attempts currently alotted in the driver to perform a
successful temperature reading when running at minimum (throttled) CPU
frequency.
Debugging suggests that the read cycle can take 160 attempts (which given
that the driver averages 80 readings from the ADC equates to one failure
on each read).
Increase the attempt limit to 200 in order to greatly reduce the
likelihood of the driver failing to perform a temperature reading,
especially at low CPU frequency.
Signed-off-by: Egor Starkov
Signed-off-by: Martyn Welch
---
v2: - Correct spelling issues in cover letter.
drivers/ata/ahci_imx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ata/ahci_imx.c b/drivers/ata/ahci_imx.c
index 787567e..a58bcc0 100644
--- a/drivers/ata/ahci_imx.c
+++ b/drivers/ata/ahci_imx.c
@@ -230,7 +230,7 @@ static int read_adc_sum(void *dev, u16 rtune_ctl_reg, void
__iomem * mmio)
{
u16 adc_out_reg, read_sum;
u32 index, read_attempt;
- const u32 attempt_limit = 100;
+ const u32 attempt_limit = 200;
imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_RTUNE_CTL, mmio);
imx_phy_reg_write(rtune_ctl_reg, mmio);
--
1.8.3.1
[PATCH] hwmon: da9052 Increase sample rate when using TSI
The TSI channel, which is usually used for touchscreen support, but can be used as 4 general purpose ADCs. When used as a touchscreen interface the touchscreen driver switches the device into 1ms sampling mode (rather than the default 10ms economy mode) as recommended by the manufacturer. When using the TSI channels as a general purpose ADC we are currently not doing this and testing suggests that this can result in ADC timeouts: [ 5827.198289] da9052 spi2.0: timeout waiting for ADC conversion interrupt [ 5827.728293] da9052 spi2.0: timeout waiting for ADC conversion interrupt [ 5993.808335] da9052 spi2.0: timeout waiting for ADC conversion interrupt [ 5994.328441] da9052 spi2.0: timeout waiting for ADC conversion interrupt [ 5994.848291] da9052 spi2.0: timeout waiting for ADC conversion interrupt Switching to the 1ms timing resolves this issue. Cc: sta...@vger.kernel.org Signed-off-by: Martyn Welch --- drivers/hwmon/da9052-hwmon.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/hwmon/da9052-hwmon.c b/drivers/hwmon/da9052-hwmon.c index 97a62f5..a973eb6 100644 --- a/drivers/hwmon/da9052-hwmon.c +++ b/drivers/hwmon/da9052-hwmon.c @@ -477,6 +477,11 @@ static int da9052_hwmon_probe(struct platform_device *pdev) /* disable touchscreen features */ da9052_reg_write(hwmon->da9052, DA9052_TSI_CONT_A_REG, 0x00); + /* Sample every 1ms */ + da9052_reg_update(hwmon->da9052, DA9052_ADC_CONT_REG, + DA9052_ADCCONT_ADCMODE, + DA9052_ADCCONT_ADCMODE); + err = da9052_request_irq(hwmon->da9052, DA9052_IRQ_TSIREADY, "tsiready-irq", da9052_tsi_datardy_irq, hwmon); -- 1.8.3.1
Re: [PATCH] vme: 8-bit status/id takes 256 values, not 255
On 10 October 2015 at 23:00, Dmitry Kalinkin wrote:
> Fixes an off by one array size.
>
The Status/ID is an 8-bit value (OK, the standard states it can be a
8, 16 or 32-bit value, however both of the chipsets we support at this
point in time support an 8-bit value), why do we need a 256th entry in
the array?
Martyn
> Signed-off-by: Dmitry Kalinkin
> ---
> drivers/vme/vme_bridge.h | 4 +++-
> include/linux/vme.h | 3 +++
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/vme/vme_bridge.h b/drivers/vme/vme_bridge.h
> index 397578a..b59cbee 100644
> --- a/drivers/vme/vme_bridge.h
> +++ b/drivers/vme/vme_bridge.h
> @@ -1,6 +1,8 @@
> #ifndef _VME_BRIDGE_H_
> #define _VME_BRIDGE_H_
>
> +#include
> +
> #define VME_CRCSR_BUF_SIZE (508*1024)
> /*
> * Resource structures
> @@ -91,7 +93,7 @@ struct vme_callback {
>
> struct vme_irq {
> int count;
> - struct vme_callback callback[255];
> + struct vme_callback callback[VME_NUM_STATUSID];
> };
>
> /* Allow 16 characters for name (including null character) */
> diff --git a/include/linux/vme.h b/include/linux/vme.h
> index c013135..71e4a6d 100644
> --- a/include/linux/vme.h
> +++ b/include/linux/vme.h
> @@ -81,6 +81,9 @@ struct vme_resource {
>
> extern struct bus_type vme_bus_type;
>
> +/* Number of VME interrupt vectors */
> +#define VME_NUM_STATUSID 256
> +
> /* VME_MAX_BRIDGES comes from the type of vme_bus_numbers */
> #define VME_MAX_BRIDGES(sizeof(unsigned int)*8)
> #define VME_MAX_SLOTS 32
> --
> 1.8.3.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv5] staging: vme_user: provide DMA functionality
On 11/10/15 01:13, Dmitry Kalinkin wrote:
This introduces a new dma device that provides a single ioctl call that
provides DMA read and write functionality to the user space.
Signed-off-by: Dmitry Kalinkin
Cc: Igor Alekseev
---
In the last reply Martyn suggested a rework of this to make it use existing
bus/vme/ctl instead of creating a new bus/vme/dma%i device and also dynamically
allocate a dma resource in each request.
I think this doesn't need those adjustments. I think that dynamic allocation
doesn't solve any practical problem that isn't caused by current kernel api.
That would depend on what resources had already been allocated to other
drivers using the kernel api and what resources the underlying bridge
had to make available. This driver will currently only load if all the
resources it wishes to expose to user space are available. That said,
such a modification is clearly separate from adding DMA support to user
space, so the argument is rather academic.
I also think that separate device is a good feature because it allows for
discovery of dma capatibility from userspace.
Given the current user space api, that's true.
The interface with separate
chardev also allows to provide DMA read() and write() syscalls that can
come handy in pair with /bin/dd.
But this patch doesn't implement such a feature does it?
(Generally happy with this for now, however couple of comments below.)
v5:
Added a validation for dma_op argument in vme_user_sg_to_dma_list(). It is
already checked in caller but we would like to silence a warning:
drivers/staging/vme/devices/vme_user.c: In function 'vme_user_ioctl.isra.4':
drivers/staging/vme/devices/vme_user.c:324:7: warning: 'dest' may be used
uninitialized in this function [-Wmaybe-uninitialized]
ret = vme_dma_list_add(dma_list, src, dest, hw_len);
^
drivers/staging/vme/devices/vme_user.c:296:52: note: 'dest' was declared
here
struct vme_dma_attr *pci_attr, *vme_attr, *src, *dest;
^
drivers/staging/vme/devices/vme_user.c:324:7: warning: 'src' may be used
uninitialized in this function [-Wmaybe-uninitialized]
ret = vme_dma_list_add(dma_list, src, dest, hw_len);
^
drivers/staging/vme/devices/vme_user.c:296:46: note: 'src' was declared here
struct vme_dma_attr *pci_attr, *vme_attr, *src, *dest;
---
drivers/staging/vme/devices/vme_user.c | 205 -
drivers/staging/vme/devices/vme_user.h | 11 ++
2 files changed, 213 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/vme/devices/vme_user.c
b/drivers/staging/vme/devices/vme_user.c
index 8e61a3b..2434e5f 100644
--- a/drivers/staging/vme/devices/vme_user.c
+++ b/drivers/staging/vme/devices/vme_user.c
@@ -79,15 +79,18 @@ static unsigned int bus_num;
* We shall support 4 masters and 4 slaves with this driver.
*/
The comment just above here (cropped in the patch) describes the
interface that this driver exposes and what is documented in
Documentation/devices.txt.
I think this comment either needs updating to reflect the changes
introduced in this patch, or deleted.
(As an aside:
The interface in Docmentation/devices.txt is an interesting oddity - it
existed before any VME drivers were present in the kernel. Given that
the driver at vmelinux.org hasn't been updated since some time in the
2.4 kernel series and the lack of mainlined drivers other than this one
using that interface, should we update that file to reflect the additions?
If we were to modify this driver sufficiently, so that chrdevs were
dynamically allocated for example, should we delete that entry?
)
#define VME_MAJOR 221 /* VME Major Device Number */
-#define VME_DEVS 9 /* Number of dev entries */
+#define VME_DEVS 10 /* Number of dev entries */
#define MASTER_MINOR 0
#define MASTER_MAX3
#define SLAVE_MINOR 4
#define SLAVE_MAX 7
#define CONTROL_MINOR 8
+#define DMA_MINOR 9
-#define PCI_BUF_SIZE 0x2 /* Size of one slave image buffer */
+#define PCI_BUF_SIZE 0x2 /* Size of one slave image buffer */
+
+#define VME_MAX_DMA_LEN0x400 /* Maximal DMA transfer length
*/
/*
* Structure to handle image related parameters.
@@ -112,7 +115,7 @@ static const int type[VME_DEVS] = { MASTER_MINOR,
MASTER_MINOR,
MASTER_MINOR, MASTER_MINOR,
SLAVE_MINOR,SLAVE_MINOR,
SLAVE_MINOR,SLAVE_MINOR,
- CONTROL_MINOR
+ CONTROL_MINOR, DMA_MINOR
};
struct vme_user_vma
Re: [PATCH] vme: 8-bit status/id takes 256 values, not 255
On 18/10/15 18:07, Dmitry Kalinkin wrote:
On Sun, Oct 18, 2015 at 9:30 AM, Martyn Welch wrote:
On 10 October 2015 at 23:00, Dmitry Kalinkin wrote:
Fixes an off by one array size.
The Status/ID is an 8-bit value (OK, the standard states it can be a
8, 16 or 32-bit value, however both of the chipsets we support at this
point in time support an 8-bit value), why do we need a 256th entry in
the array?
Hi Martyn,
8 bit signal spans 256 values from 8'b_ to 8'b_.
In order to serve that we need a C array of size 256.
callback[255]; in the original code means that array has 255 elements
with indices from 0 to 254, there would be no way to register callback
for a valid Status/ID value of 255 (aka 8'b_). For that we
need a 256th element.
Err, yep. (Curses self for being so stupid.)
Signed-off-by: Martyn Welch
Dmitri
Martyn
Signed-off-by: Dmitry Kalinkin
---
drivers/vme/vme_bridge.h | 4 +++-
include/linux/vme.h | 3 +++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/vme/vme_bridge.h b/drivers/vme/vme_bridge.h
index 397578a..b59cbee 100644
--- a/drivers/vme/vme_bridge.h
+++ b/drivers/vme/vme_bridge.h
@@ -1,6 +1,8 @@
#ifndef _VME_BRIDGE_H_
#define _VME_BRIDGE_H_
+#include
+
#define VME_CRCSR_BUF_SIZE (508*1024)
/*
* Resource structures
@@ -91,7 +93,7 @@ struct vme_callback {
struct vme_irq {
int count;
- struct vme_callback callback[255];
+ struct vme_callback callback[VME_NUM_STATUSID];
};
/* Allow 16 characters for name (including null character) */
diff --git a/include/linux/vme.h b/include/linux/vme.h
index c013135..71e4a6d 100644
--- a/include/linux/vme.h
+++ b/include/linux/vme.h
@@ -81,6 +81,9 @@ struct vme_resource {
extern struct bus_type vme_bus_type;
+/* Number of VME interrupt vectors */
+#define VME_NUM_STATUSID 256
+
/* VME_MAX_BRIDGES comes from the type of vme_bus_numbers */
#define VME_MAX_BRIDGES(sizeof(unsigned int)*8)
#define VME_MAX_SLOTS 32
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv5] staging: vme_user: provide DMA functionality
On 18/10/15 18:53, Dmitry Kalinkin wrote: On Sun, Oct 18, 2015 at 10:31 AM, Martyn Welch wrote: On 11/10/15 01:13, Dmitry Kalinkin wrote: This introduces a new dma device that provides a single ioctl call that provides DMA read and write functionality to the user space. Signed-off-by: Dmitry Kalinkin Cc: Igor Alekseev --- In the last reply Martyn suggested a rework of this to make it use existing bus/vme/ctl instead of creating a new bus/vme/dma%i device and also dynamically allocate a dma resource in each request. I think this doesn't need those adjustments. I think that dynamic allocation doesn't solve any practical problem that isn't caused by current kernel api. That would depend on what resources had already been allocated to other drivers using the kernel api and what resources the underlying bridge had to make available. This driver will currently only load if all the resources it wishes to expose to user space are available. That said, such a modification is clearly separate from adding DMA support to user space, so the argument is rather academic. Other drives meaning vme_pio, I don't see any others. All this time we are discussing how many GE PIO boards one can plug into a crate with or without vme_user. Most of people have zero of them. Also, VME DMA API has no users in kernel, we are just adding one now. Unfortunately not all users of Linux upstream or even publicise their drivers. This is especially true of some industries where VME gets used. The number of VME windows is limited, so having a user space shim either hog or limit the number of resources available either in kernel space or user space is not an optimal solution. I also think that separate device is a good feature because it allows for discovery of dma capatibility from userspace. Given the current user space api, that's true. The interface with separate chardev also allows to provide DMA read() and write() syscalls that can come handy in pair with /bin/dd. But this patch doesn't implement such a feature does it? Actually, initial (never published) version of this patch exposed read(),write(), and an ioctl to set the access cycle. It was working, but with subtlety for A64 addressing. I come across some problems when using large offsets that would not fit in signed long long. I was using FMODE_UNSIGNED_OFFSET to fix the kernel side of things, but it seemed like userspace didn't like the "negative" offsets. I've looked a bit at glibc sources and decided to give up. Now that I remember this, my original argument is kind of busted. (Generally happy with this for now, however couple of comments below.) v5: Added a validation for dma_op argument in vme_user_sg_to_dma_list(). It is already checked in caller but we would like to silence a warning: drivers/staging/vme/devices/vme_user.c: In function 'vme_user_ioctl.isra.4': drivers/staging/vme/devices/vme_user.c:324:7: warning: 'dest' may be used uninitialized in this function [-Wmaybe-uninitialized] ret = vme_dma_list_add(dma_list, src, dest, hw_len); ^ drivers/staging/vme/devices/vme_user.c:296:52: note: 'dest' was declared here struct vme_dma_attr *pci_attr, *vme_attr, *src, *dest; ^ drivers/staging/vme/devices/vme_user.c:324:7: warning: 'src' may be used uninitialized in this function [-Wmaybe-uninitialized] ret = vme_dma_list_add(dma_list, src, dest, hw_len); ^ drivers/staging/vme/devices/vme_user.c:296:46: note: 'src' was declared here struct vme_dma_attr *pci_attr, *vme_attr, *src, *dest; --- drivers/staging/vme/devices/vme_user.c | 205 - drivers/staging/vme/devices/vme_user.h | 11 ++ 2 files changed, 213 insertions(+), 3 deletions(-) diff --git a/drivers/staging/vme/devices/vme_user.c b/drivers/staging/vme/devices/vme_user.c index 8e61a3b..2434e5f 100644 --- a/drivers/staging/vme/devices/vme_user.c +++ b/drivers/staging/vme/devices/vme_user.c @@ -79,15 +79,18 @@ static unsigned int bus_num; * We shall support 4 masters and 4 slaves with this driver. */ The comment just above here (cropped in the patch) describes the interface that this driver exposes and what is documented in Documentation/devices.txt. I've come across a long time ago and at the time I realized that this document is generally outdated and is not required to be updated. First, "Last revised: 6th April 2009" Second, the device path information is long obsolete in the light of udev. Third, they want submissions on a separate list Fourth, "20 block Hitachi CD-ROM (under development) 0 = /dev/hitcd" -- this is not for real. Yup, I agree, devices.txt is probably well out of date and is a product of long since deprecated practices. That said, the comment in vme_user.
Re: [PATCH] vme: ca91cx42: remove redundant variable i
On Sat, Jul 14, 2018 at 05:33:32PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Variable i is being assigned but is never used hence it is redundant
> and can be removed.
>
> Cleans up clang warning:
> warning: variable 'i' set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: Colin Ian King
Reviewed-by: Martyn Welch
> ---
> drivers/vme/bridges/vme_ca91cx42.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/vme/bridges/vme_ca91cx42.c
> b/drivers/vme/bridges/vme_ca91cx42.c
> index 5dd284008630..53bdc256805f 100644
> --- a/drivers/vme/bridges/vme_ca91cx42.c
> +++ b/drivers/vme/bridges/vme_ca91cx42.c
> @@ -970,7 +970,6 @@ static unsigned int ca91cx42_master_rmw(struct
> vme_master_resource *image,
> {
> u32 result;
> uintptr_t pci_addr;
> - int i;
> struct ca91cx42_driver *bridge;
> struct device *dev;
>
> @@ -978,7 +977,6 @@ static unsigned int ca91cx42_master_rmw(struct
> vme_master_resource *image,
> dev = image->parent->parent;
>
> /* Find the PCI address that maps to the desired VME address */
> - i = image->number;
>
> /* Locking as we can only do one of these at a time */
> mutex_lock(&bridge->vme_rmw);
> --
> 2.17.1
>
Re: [PATCH] MAINTAINERS: Update E-mail address
On Tue, 2018-07-10 at 16:47 +0200, Peter Senna Tschudin wrote: > Update my E-mail address on MAINTAINERS file. > > Signed-off-by: Peter Senna Tschudin Acked-by: Martyn Welch > --- > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index a29d10f25e27..3204ea8c2a8f 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -9133,7 +9133,7 @@ S: Maintained > F: drivers/usb/mtu3/ > > MEGACHIPS STDP-GE-B850V3-FW LVDS/DP++ BRIDGES > -M: Peter Senna Tschudin > +M: Peter Senna Tschudin > M: Martin Donnelly > M: Martyn Welch > S: Maintained
[PATCH 2/2] ARM: dts: imx6: Add support for Phytec phyBOARD i.MX6UL Segin
The Phytec phyBOARD Segin is i.MX6 based SBC, available with either an
i.MX6UL or i.MX6ULL SOM and various add-on boards.
The following adds support for the "Full Featured" version of the Segin,
which is provided with the i.MX6UL SOM and the PEB-EVAL-01 evaluation
module.
Its hardware specifications are:
* 512MB DDR3 memory
* 512MB NAND flash
* Dual 10/100 Ethernet
* USB Host and USB OTG
* RS232
* MicroSD external storage
* Audio, RS232, I2C, SPI, CAN headers
* Further I/O options via A/V and Expansion headers
Signed-off-by: Martyn Welch
---
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/imx6ul-phytec-pcl063.dtsi | 152
.../boot/dts/imx6ul-phytec-peb-eval-01.dtsi | 55 +++
.../dts/imx6ul-phytec-phyboard-segin-full.dts | 103 ++
.../dts/imx6ul-phytec-phyboard-segin.dtsi | 341 ++
5 files changed, 652 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ul-phytec-pcl063.dtsi
create mode 100644 arch/arm/boot/dts/imx6ul-phytec-peb-eval-01.dtsi
create mode 100644 arch/arm/boot/dts/imx6ul-phytec-phyboard-segin-full.dts
create mode 100644 arch/arm/boot/dts/imx6ul-phytec-phyboard-segin.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b0e966d625b9..6ca286f6b37c 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -557,6 +557,7 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-liteboard.dtb \
imx6ul-opos6uldev.dtb \
imx6ul-pico-hobbit.dtb \
+ imx6ul-phytec-phyboard-segin-full.dtb \
imx6ul-tx6ul-0010.dtb \
imx6ul-tx6ul-0011.dtb \
imx6ul-tx6ul-mainboard.dtb \
diff --git a/arch/arm/boot/dts/imx6ul-phytec-pcl063.dtsi
b/arch/arm/boot/dts/imx6ul-phytec-pcl063.dtsi
new file mode 100644
index ..ede24105044f
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-phytec-pcl063.dtsi
@@ -0,0 +1,152 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016 PHYTEC Messtechnik GmbH
+ * Author: Christian Hemp
+ */
+
+#include
+#include
+#include
+#include "imx6ul.dtsi"
+
+/ {
+
+ model = "Phytec phyCORE i.MX6 UltraLite";
+ compatible = "phytec,imx6ul-pcl063", "fsl,imx6ul";
+
+ chosen {
+ stdout-path = &uart1;
+ };
+
+
+ /*
+* Set the minimum memory size here and
+* let the bootloader set the real size.
+*/
+ memory {
+ reg = <0x8000 0x800>;
+ };
+
+ gpio_leds_som: somleds {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpioleds_som>;
+ compatible = "gpio-leds";
+ status = "okay";
+
+ som_green {
+ label = "phycore:green";
+ gpios = <&gpio5 4 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+};
+
+&fec1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet1>;
+ phy-mode = "rmii";
+ phy-handle = <ðphy0>;
+ status = "okay";
+
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@1 {
+ reg = <1>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+ micrel,led-mode = <1>;
+ clocks = <&clks IMX6UL_CLK_ENET_REF>;
+ clock-names = "rmii-ref";
+ };
+ };
+};
+
+&gpmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpmi_nand>;
+ nand-on-flash-bbt;
+ status = "okay";
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 =<&pinctrl_i2c1>;
+ clock-frequency = <10>;
+ status = "okay";
+
+ eeprom@52 {
+ compatible = "catalyst,24c32", "atmel,24c32";
+ reg = <0x52>;
+ };
+};
+
+&snvs_poweroff {
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+
+ pinctrl_enet1: enet1grp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO07__ENET1_MDC 0x1b0b0
+ MX6UL_PAD_GPIO1_IO06__ENET1_MDIO0x1b0b0
+ MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b0b0
+ MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x1b0b0
+ MX6UL
[PATCH 1/2] dt-bindings: Add vendor prefix for Catalyst Semiconductor
Add vendor prefix "catalyst" for Catalyst Semiconductor which is already in use but undocumented. Signed-off-by: Martyn Welch --- 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 4b1a2a8fcc16..bbc41483e81b 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -65,6 +65,7 @@ bticino Bticino International calxedaCalxeda capellaCapella Microsystems, Inc cascodaCascoda, Ltd. +catalyst Catalyst Semiconductor, Inc cavium Cavium, Inc. cdns Cadence Design Systems Inc. ceva Ceva, Inc. -- 2.19.2
Re: [PATCH] mailbox, remoteproc: omap2+: fix compile testing
On Mon, 2024-09-09 at 20:38 +, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Selecting CONFIG_OMAP2PLUS_MBOX while compile testing
> causes a build failure:
>
> WARNING: unmet direct dependencies detected for OMAP2PLUS_MBOX
> Depends on [n]: MAILBOX [=y] && (ARCH_OMAP2PLUS || ARCH_K3)
> Selected by [m]:
> - TI_K3_M4_REMOTEPROC [=m] && REMOTEPROC [=y] && (ARCH_K3 ||
> COMPILE_TEST [=y])
>
> Using 'select' to force-enable another subsystem is generally
> a mistake and causes problems such as this one, so change the
> three drivers that link against this driver to use 'depends on'
> instead, and ensure the driver itself can be compile tested
> regardless of the platform.
>
> When compile-testing without CONFIG_TI_SCI_PROTOCOL=m, there
> is a chance for a link failure, so add a careful dependency
> on that.
>
> arm-linux-gnueabi-ld: drivers/remoteproc/ti_k3_m4_remoteproc.o: in
> function `k3_m4_rproc_probe':
> ti_k3_m4_remoteproc.c:(.text.k3_m4_rproc_probe+0x76): undefined
> reference to `devm_ti_sci_get_by_phandle'
>
> Fixes: ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for
> M4F subsystem")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/mailbox/Kconfig | 2 +-
> drivers/mailbox/omap-mailbox.c | 2 +-
> drivers/remoteproc/Kconfig | 10 --
> 3 files changed, 6 insertions(+), 8 deletions(-)
>
Looks good to me:
Reviewed-by: Martyn Welch
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> index 4eed97295927..ecaf78beb934 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -73,7 +73,7 @@ config ARMADA_37XX_RWTM_MBOX
>
> config OMAP2PLUS_MBOX
> tristate "OMAP2+ Mailbox framework support"
> - depends on ARCH_OMAP2PLUS || ARCH_K3
> + depends on ARCH_OMAP2PLUS || ARCH_K3 || COMPILE_TEST
> help
> Mailbox implementation for OMAP family chips with hardware
> for
> interprocessor communication involving DSP, IVA1.0 and
> IVA2 in
> diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-
> mailbox.c
> index 7a87424657a1..6797770474a5 100644
> --- a/drivers/mailbox/omap-mailbox.c
> +++ b/drivers/mailbox/omap-mailbox.c
> @@ -603,7 +603,7 @@ static struct platform_driver omap_mbox_driver =
> {
> .driver = {
> .name = "omap-mailbox",
> .pm = &omap_mbox_pm_ops,
> - .of_match_table =
> of_match_ptr(omap_mailbox_of_match),
> + .of_match_table = omap_mailbox_of_match,
> },
> };
> module_platform_driver(omap_mbox_driver);
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 0f0862e20a93..62f8548fb46a 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -330,8 +330,7 @@ config STM32_RPROC
> config TI_K3_DSP_REMOTEPROC
> tristate "TI K3 DSP remoteproc support"
> depends on ARCH_K3
> - select MAILBOX
> - select OMAP2PLUS_MBOX
> + depends on OMAP2PLUS_MBOX
> help
> Say m here to support TI's C66x and C71x DSP remote
> processor
> subsystems on various TI K3 family of SoCs through the
> remote
> @@ -343,8 +342,8 @@ config TI_K3_DSP_REMOTEPROC
> config TI_K3_M4_REMOTEPROC
> tristate "TI K3 M4 remoteproc support"
> depends on ARCH_K3 || COMPILE_TEST
> - select MAILBOX
> - select OMAP2PLUS_MBOX
> + depends on TI_SCI_PROTOCOL || (COMPILE_TEST &&
> TI_SCI_PROTOCOL=n)
> + depends on OMAP2PLUS_MBOX
> help
> Say m here to support TI's M4 remote processor subsystems
> on various TI K3 family of SoCs through the remote
> processor
> @@ -356,8 +355,7 @@ config TI_K3_M4_REMOTEPROC
> config TI_K3_R5_REMOTEPROC
> tristate "TI K3 R5 remoteproc support"
> depends on ARCH_K3
> - select MAILBOX
> - select OMAP2PLUS_MBOX
> + depends on OMAP2PLUS_MBOX
> help
> Say m here to support TI's R5F remote processor subsystems
> on various TI K3 family of SoCs through the remote
> processor
Re: PATCH[[vme/bridges/vme_ca91cx42.c:1382: Bad if test Bug Fix]
On 16/06/14 10:56, Dan Carpenter wrote: On Mon, Jun 16, 2014 at 10:47:25AM +0100, Martyn Welch wrote: Nick, Sorry for the delay in responding. I'm staring at the manual for the ca91c142 and the relevant bits in the VSIx_CTL registers definitely need to be set to 0 for A16, likewise with the LM_CTL register. The pattern (3<<16) would enable one of the "reserved" address spaces. Nick emailed me privately that this was a static checker warning. These warnings are often false positives... But I'm worried about the test: if ((ctl & CA91CX42_VSI_CTL_VAS_M) == CA91CX42_VSI_CTL_VAS_A16) *aspace = VME_A16; That could be true when we didn't intend it. If I'm not mistaken, CA91CX42_VSI_CTL_VAS_A16 is currently defined as 0. So: if ((ctl & (7<<16) == 0) *aspace = VME_A16; Which looks right to me, it's checking to see if the relevant bits in the register are all zero, am I missing something obvious? Martyn -- Martyn Welch (Lead Software Engineer) | Registered in England and Wales GE Intelligent Platforms | (3828642) at 100 Barbirolli Square T +44(0)1327322748 | Manchester, M2 3AB E martyn.we...@ge.com | VAT:GB 927559189 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH[[vme/bridges/vme_ca91cx42.c:1382: Bad if test Bug Fix]
Nick,
Sorry for the delay in responding.
I'm staring at the manual for the ca91c142 and the relevant bits in the
VSIx_CTL registers definitely need to be set to 0 for A16, likewise with
the LM_CTL register. The pattern (3<<16) would enable one of the
"reserved" address spaces.
Martyn
On 12/06/14 15:33, nick wrote:
Here is the fixed patch. Having issues with using Thunderbird
so just used Evolution for now.
Nick
--- drivers/vme/bridges/vme_ca91cx42.h.orig 2014-06-11 22:50:29.339671939
-0400
+++ drivers/vme/bridges/vme_ca91cx42.h 2014-06-11 23:15:36.027685173 -0400
Fixes bug issues with wrong bus width in if statments in vme_ca91cx42.c
Signed-off-by: Nicholas Krause
@@ -526,7 +526,7 @@ static const int CA91CX42_LINT_LM[] = {
#define CA91CX42_VSI_CTL_SUPER_SUPR (1<<21)
#define CA91CX42_VSI_CTL_VAS_M(7<<16)
-#define CA91CX42_VSI_CTL_VAS_A16 0
+#define CA91CX42_VSI_CTL_VAS_A16 (3<<16)
#define CA91CX42_VSI_CTL_VAS_A24 (1<<16)
#define CA91CX42_VSI_CTL_VAS_A32 (1<<17)
#define CA91CX42_VSI_CTL_VAS_USER1(3<<17)
@@ -549,7 +549,7 @@ static const int CA91CX42_LINT_LM[] = {
#define CA91CX42_LM_CTL_SUPR (1<<21)
#define CA91CX42_LM_CTL_NPRIV (1<<20)
#define CA91CX42_LM_CTL_AS_M (5<<16)
-#define CA91CX42_LM_CTL_AS_A16 0
+#define CA91CX42_LM_CTL_AS_A16 (3<<16)
#define CA91CX42_LM_CTL_AS_A24 (1<<16)
#define CA91CX42_LM_CTL_AS_A32(1<<17)
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
T +44(0)1327322748 | Manchester, M2 3AB
E martyn.we...@ge.com | VAT:GB 927559189
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 08/16] staging: vme_user: provide DMA functionality
On 06/07/15 18:24, Dmitry Kalinkin wrote: Some functionality was dropped as it was not good practice >(such as receiving VME interrupts in user space, it's not really doable if >the slave card is Release On Register Access rather than Release on >Acknowledge), Didn't know about RORA. I wonder how different this is compared to the PCI bus case. Little I suspect. What it does mean is that there's no generic mechanism for clearing down an interrupt, so a device specific interrupt routine is required, which needs to be in kernel space. >so the interface became more of a debug mechanism for me. >Others have clearly found it provides enough for them to allow drivers to be >written in user space. > >I was thinking that the opposite might be better, no windows were mapped at >module load, windows could be allocated and mapped using the control device. >This would ensure that unused resources were still available for kernel >based drivers and would mean the driver wouldn't be pre-allocating a bunch >of fairly substantially sized slave window buffers (the buffers could also >be allocated to match the size of the slave window requested). What do you >think? I'm not a VME expert, but it seems that VME windows are a quiet limited resource no matter how you allocate your resources. Theoretically we could put up to 32 different boards in a single crate, so there won't be enough windows for each driver to allocate. That said, there is no way around this when putting together a really heterogeneous VME system. To overcome such problem, one could develop a different kernel API that would not provide windows to the drivers, but handle reads and writes by reconfiguring windows on the fly, which in turn would introduce more latency. Those who need such API are welcome to develop it:) The aim of the existing APIs is to provide a mechanism for allocating resources. You're right, the resources are limited when scaling to a 32 slot crate. There's a number of ways to share the resources, though they tend to all have trade offs. My experience has been that the majority of VME systems don't tend to stretch up to 32 cards. As for dynamic vme_user device allocation, I don't see the point in this. The only existing kernel VME driver allocates windows in advance, user is just to make sure to leave one free window if she wants to use that. Module parameter for window count will be dynamic enough to handle that. If vme_user grabs all the VME windows, there are no windows available for any kernel level VME drivers to use. If a kernel level driver loads before vme_user and is allocated a window, if vme_user demands 8 windows (and assuming it doesn't deal with some already having been allocated gracefully, which it doesn't at the moment) then it doesn't load. Dynamic allocation would leave "unused" resources available rather than prospectively hogging them. -- Martyn Welch (Lead Software Engineer) | Registered in England and Wales GE Intelligent Platforms | (3828642) at 100 Barbirolli Square T +44(0)1327322748 | Manchester, M2 3AB E martyn.we...@ge.com | VAT:GB 927559189 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 08/16] staging: vme_user: provide DMA functionality
On 07/07/15 08:08, Alessio Igor Bogani wrote: I would be glad to try it if the maintainer is willing to receive this type of changes. Such requirements have come up in the past. I'd welcome such support being contributed to the kernel. My view has been that such an API could be built on top of the existing API. Does that seem workable to you? -- Martyn Welch (Lead Software Engineer) | Registered in England and Wales GE Intelligent Platforms | (3828642) at 100 Barbirolli Square T +44(0)1327322748 | Manchester, M2 3AB E martyn.we...@ge.com | VAT:GB 927559189 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 08/16] staging: vme_user: provide DMA functionality
On 07/07/15 13:51, Alessio Igor Bogani wrote: Current VME stack links windows not to the boards, but to device drivers. >Driver >could potentially minimise window usage within it’s scope (any sort of >window >reusing, like mapping whole A16 once to be used with all boards), but this >won’t >work across multiple drivers. Even if all of your drivers are window-wise >economic, >they will still need some amount of windows per each driver. Not that we >have that >many kernel drivers... Yes you can share a window/image between all boards of the same type (in effect we are porting our drivers in this way)*but* it isn't the expected way to work (see Documentation/vme_api.txt struct vme_driver's probe() and match() functions and the GE PIO2 VME driver). I think it's perfectly valid to use a single window to dynamically map to the address space belonging to one of a number of devices supported by a single driver. I think this is almost preferable to mapping a large window over a large portion of the VME address space to drive a number of devices as (depending on there spacing in the VME address space) the latter could cause issues with filling available PCI address space. Admittedly this is more of a problem on 32-bit systems, but... -- Martyn Welch (Lead Software Engineer) | Registered in England and Wales GE Intelligent Platforms | (3828642) at 100 Barbirolli Square T +44(0)1327322748 | Manchester, M2 3AB E martyn.we...@ge.com | VAT:GB 927559189 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 08/16] staging: vme_user: provide DMA functionality
On 07/07/15 11:52, Dmitry Kalinkin wrote: The API I had in mind would have only vme_master_read and vme_master_write that would take absolute addresses (not relative to any window). These variants of access functions would then try to reuse any window that is already able to serve the request or wait for a free window and reconfigure it for the need of the request. I'm a little concerned by the latency this might cause, especially if there is one device which is negatively affected by latency. Handling RORA interrupts would be "interesting" if all the windows were dynamically allocated at the time at which an interrupt came in. Martyn -- Martyn Welch (Lead Software Engineer) | Registered in England and Wales GE Intelligent Platforms | (3828642) at 100 Barbirolli Square T +44(0)1327322748 | Manchester, M2 3AB E martyn.we...@ge.com | VAT:GB 927559189 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Generic VME UIO
h b/drivers/vme/vme_bridge.h
index 37d2fd7..a3ef63b 100644
--- a/drivers/vme/vme_bridge.h
+++ b/drivers/vme/vme_bridge.h
@@ -1,6 +1,8 @@
#ifndef _VME_BRIDGE_H_
#define _VME_BRIDGE_H_
+#include
+
#define VME_CRCSR_BUF_SIZE (508*1024)
/*
* Resource structures
@@ -88,7 +90,7 @@ struct vme_callback {
struct vme_irq {
int count;
- struct vme_callback callback[256];
+ struct vme_callback callback[VME_NUM_STATUSID];
};
/* Allow 16 characters for name (including null character) */
diff --git a/include/linux/vme.h b/include/linux/vme.h
index c013135..71e4a6d 100644
--- a/include/linux/vme.h
+++ b/include/linux/vme.h
@@ -81,6 +81,9 @@ struct vme_resource {
extern struct bus_type vme_bus_type;
+/* Number of VME interrupt vectors */
+#define VME_NUM_STATUSID 256
+
/* VME_MAX_BRIDGES comes from the type of vme_bus_numbers */
#define VME_MAX_BRIDGES (sizeof(unsigned int)*8)
#define VME_MAX_SLOTS 32
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
T +44(0)1327322748 | Manchester, M2 3AB
E martyn.we...@ge.com | VAT:GB 927559189
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers: staging: vme: Fixed code style issues
On 13/11/15 20:01, Egor Uleyskiy wrote:
From: Egor Uleyskiy
* Fixed indention
* Deleted extra empty lines
* Constructions that looks like
card = kzalloc(sizeof(struct pio2_card), GFP_KERNEL);
are changed to
card = kzalloc(sizeof(*card), GFP_KERNEL);
Also:
* Removing extra bracketing from uses of the address operator
* Use preferred null return check style
Other than that:
Acked-by: Martyn Welch
Martyn
Signed-off-by: Egor Uleyskiy
---
drivers/staging/vme/devices/vme_pio2_cntr.c | 2 +-
drivers/staging/vme/devices/vme_pio2_core.c | 20 +-
drivers/staging/vme/devices/vme_pio2_gpio.c | 32 ++---
drivers/staging/vme/devices/vme_user.h | 2 --
4 files changed, 26 insertions(+), 30 deletions(-)
diff --git a/drivers/staging/vme/devices/vme_pio2_cntr.c
b/drivers/staging/vme/devices/vme_pio2_cntr.c
index 6335471..486c30c 100644
--- a/drivers/staging/vme/devices/vme_pio2_cntr.c
+++ b/drivers/staging/vme/devices/vme_pio2_cntr.c
@@ -61,7 +61,7 @@ int pio2_cntr_reset(struct pio2_card *card)
/* Ensure all counter interrupts are cleared */
do {
retval = vme_master_read(card->window, ®, 1,
- PIO2_REGS_INT_STAT_CNTR);
+PIO2_REGS_INT_STAT_CNTR);
if (retval < 0)
return retval;
} while (reg != 0);
diff --git a/drivers/staging/vme/devices/vme_pio2_core.c
b/drivers/staging/vme/devices/vme_pio2_core.c
index 35c6ce5..28a6ab6 100644
--- a/drivers/staging/vme/devices/vme_pio2_core.c
+++ b/drivers/staging/vme/devices/vme_pio2_core.c
@@ -90,7 +90,7 @@ static void pio2_int(int level, int vector, void *ptr)
case 4:
/* Channels 0 to 7 */
retval = vme_master_read(card->window, ®, 1,
- PIO2_REGS_INT_STAT[vec - 1]);
+PIO2_REGS_INT_STAT[vec - 1]);
if (retval < 0) {
dev_err(&card->vdev->dev,
"Unable to read IRQ status register\n");
@@ -100,8 +100,8 @@ static void pio2_int(int level, int vector, void *ptr)
channel = ((vec - 1) * 8) + i;
if (reg & PIO2_CHANNEL_BIT[channel])
dev_info(&card->vdev->dev,
- "Interrupt on I/O channel %d\n",
- channel);
+"Interrupt on I/O channel %d\n",
+channel);
}
break;
case 5:
@@ -215,7 +215,7 @@ static int pio2_probe(struct vme_dev *vdev)
u8 reg;
int vec;
- card = kzalloc(sizeof(struct pio2_card), GFP_KERNEL);
+ card = kzalloc(sizeof(*card), GFP_KERNEL);
if (!card) {
retval = -ENOMEM;
goto err_struct;
@@ -289,7 +289,7 @@ static int pio2_probe(struct vme_dev *vdev)
}
retval = vme_master_set(card->window, 1, card->base, 0x1, VME_A24,
- (VME_SCT | VME_USER | VME_DATA), VME_D16);
+ (VME_SCT | VME_USER | VME_DATA), VME_D16);
if (retval) {
dev_err(&card->vdev->dev,
"Unable to configure VME master resource\n");
@@ -335,7 +335,7 @@ static int pio2_probe(struct vme_dev *vdev)
/* Set VME vector */
retval = vme_master_write(card->window, &card->irq_vector, 1,
- PIO2_REGS_VME_VECTOR);
+ PIO2_REGS_VME_VECTOR);
if (retval < 0)
return retval;
@@ -343,7 +343,7 @@ static int pio2_probe(struct vme_dev *vdev)
vec = card->irq_vector | PIO2_VME_VECTOR_SPUR;
retval = vme_irq_request(vdev, card->irq_level, vec,
- &pio2_int, (void *)card);
+&pio2_int, (void *)card);
if (retval < 0) {
dev_err(&card->vdev->dev,
"Unable to attach VME interrupt vector0x%x, level
0x%x\n",
@@ -356,7 +356,7 @@ static int pio2_probe(struct vme_dev *vdev)
vec = card->irq_vector | PIO2_VECTOR_BANK[i];
retval = vme_irq_request(vdev, card->irq_level, vec,
- &pio2_int, (void *)card);
+&pio2_int, (void *)card);
if (retval < 0) {
dev_err(&card->vdev->dev,
"Unable to attach VME interrupt vector0x%x, level
0x%x\n",
@@ -370,7 +370,7 @@ static int pio2_probe(struct vme_dev *vdev)
vec = card->irq_vector | PIO2_VECTOR_CNTR[i];
retval = vme_irq_request(vdev, card->irq_level, vec
[PATCH 3/3] ARM: dts: Addition of binding for gpio switches on peach-pi
The peach pi has a GPIO connected to the firmware write protect, developer
mode and recovery mode lines (which are primarily controlled via external
switches on developer test board). This patch adds the required nodes to
the device tree to configure the pinmuxing and allow these to be read from
user space.
Signed-off-by: Martyn Welch
---
arch/arm/boot/dts/exynos5800-peach-pi.dts | 46 +++
1 file changed, 46 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 49a4f43..2937372 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -53,6 +53,31 @@
};
};
+ gpio-switch {
+ compatible = "gpio-switch";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&wp_gpio &dev_mode &rec_mode>;
+
+ write-protect {
+ label = "write-protect";
+ gpios = <&gpx3 0 GPIO_ACTIVE_LOW>;
+ read-only;
+ };
+
+ developer-switch {
+ label = "developer-switch";
+ gpios = <&gpx1 3 GPIO_ACTIVE_HIGH>;
+ read-only;
+ };
+
+ recovery-switch {
+ label = "recovery-switch";
+ gpios = <&gpx0 7 GPIO_ACTIVE_LOW>;
+ read-only;
+ };
+ };
+
gpio-keys {
compatible = "gpio-keys";
@@ -731,6 +756,13 @@
samsung,pin-val = <0>;
};
+ rec_mode: rec-mode {
+ samsung,pins = "gpx0-7";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
tpm_irq: tpm-irq {
samsung,pins = "gpx1-0";
samsung,pin-function = <0>;
@@ -752,6 +784,13 @@
samsung,pin-drv = <0>;
};
+ dev_mode: dev-mode {
+ samsung,pins = "gpx1-3";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
ec_irq: ec-irq {
samsung,pins = "gpx1-5";
samsung,pin-function = <0>;
@@ -773,6 +812,13 @@
samsung,pin-drv = <0>;
};
+ wp_gpio: wp_gpio {
+ samsung,pins = "gpx3-0";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
max77802_irq: max77802-irq {
samsung,pins = "gpx3-1";
samsung,pin-function = <0>;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] Device tree binding documentation for gpio-switch
This patch adds documentation for the gpio-switch binding. This binding
provides a mechanism to bind named links to gpio, with the primary
purpose of enabling standardised access to switches that might be standard
across a group of devices but implemented differently on each device.
Signed-off-by: Martyn Welch
---
.../devicetree/bindings/misc/gpio-switch.txt | 47 ++
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/gpio-switch.txt
diff --git a/Documentation/devicetree/bindings/misc/gpio-switch.txt
b/Documentation/devicetree/bindings/misc/gpio-switch.txt
new file mode 100644
index 000..13528bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/gpio-switch.txt
@@ -0,0 +1,47 @@
+Device-Tree bindings for gpio attached switches.
+
+This provides a mechanism to provide a named link to specified gpios. This can
+be useful in instances such as when theres a need to monitor a switch, which is
+common across a family of devices, but attached to different gpios and even
+implemented in different ways on differnet devices.
+
+Required properties:
+ - compatible = "gpio-switch";
+
+Each signal is represented as a sub-node of "gpio-switch". The naming of
+sub-nodes is arbitrary.
+
+Required sub-node properties:
+
+ - label: Name to be given to gpio switch.
+ - gpios: OF device-tree gpio specification.
+
+Optional sub-node properties:
+
+ - read-only: Boolean flag to mark the gpio as read-only, i.e. the line
+ should not be driven by the host.
+
+Example nodes:
+
+gpio-switch {
+compatible = "gpio-switch";
+
+write-protect {
+label = "write-protect";
+gpios = <&gpx3 0 GPIO_ACTIVE_LOW>;
+read-only;
+};
+
+developer-switch {
+label = "developer-switch";
+gpios = <&gpx1 3 GPIO_ACTIVE_HIGH>;
+read-only;
+};
+
+recovery-switch {
+label = "recovery-switch";
+gpios = <&gpx0 7 GPIO_ACTIVE_LOW>;
+read-only;
+};
+};
+
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] Add support for monitoring gpio switches
Select Chromebooks have gpio attached to switches used to cause the
firmware to enter alternative modes of operation and/or control other
device characteristics (such as write protection on flash devices). This
patch adds a driver that exposes a read-only interface to allow these
signals to be read from user space.
This functionality has been generalised to provide support for any device
with device tree support which needs to identify a gpio as being used for a
specific task.
Signed-off-by: Martyn Welch
---
drivers/misc/Kconfig | 11
drivers/misc/Makefile | 1 +
drivers/misc/gpio-switch.c | 160 +
3 files changed, 172 insertions(+)
create mode 100644 drivers/misc/gpio-switch.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 22892c7..d24367c 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -525,6 +525,17 @@ config VEXPRESS_SYSCFG
bus. System Configuration interface is one of the possible means
of generating transactions on this bus.
+config GPIO_SWITCH
+ tristate "GPIO Switch driver"
+ depends on GPIO_SYSFS
+ ---help---
+Some devices have gpio attached to dedicated switches, an example of
+this are chromebooks (where connection to some switches for predefined
+purposes are provided on the generic development card). This driver
+provides the ability to create consistently named sysfs entries to the
+functionally equivalent signals across a range of devices. This
+functionality currently requires a device which supports device tree.
+
source "drivers/misc/c2port/Kconfig"
source "drivers/misc/eeprom/Kconfig"
source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 537d7f3..7a7e11a 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -56,3 +56,4 @@ obj-$(CONFIG_GENWQE) += genwqe/
obj-$(CONFIG_ECHO) += echo/
obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
obj-$(CONFIG_CXL_BASE) += cxl/
+obj-$(CONFIG_GPIO_SWITCH) += gpio-switch.o
diff --git a/drivers/misc/gpio-switch.c b/drivers/misc/gpio-switch.c
new file mode 100644
index 000..1f381d6
--- /dev/null
+++ b/drivers/misc/gpio-switch.c
@@ -0,0 +1,160 @@
+/*
+ * Copyright (C) 2015 Collabora Ltd.
+ *
+ * based on vendor driver,
+ *
+ * Copyright (C) 2011 The Chromium OS Authors
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct gpio_switch_gpio_info {
+ int gpio;
+ const char *link;
+};
+
+static int dt_gpio_init(struct platform_device *pdev, struct device_node
*child,
+ struct gpio_switch_gpio_info *gpio)
+{
+ int err;
+ enum of_gpio_flags of_flags;
+ unsigned long flags = GPIOF_DIR_IN | GPIOF_EXPORT;
+ const char *name;
+
+ err = of_property_read_string(child, "label", &name);
+ if (err)
+ return err;
+
+ gpio->gpio = of_get_named_gpio_flags(child, "gpios", 0, &of_flags);
+ if (!gpio_is_valid(gpio->gpio)) {
+ err = -EINVAL;
+ goto err_prop;
+ }
+
+ if (of_flags & OF_GPIO_ACTIVE_LOW)
+ flags |= GPIOF_ACTIVE_LOW;
+
+ if (!of_property_read_bool(child, "read-only"))
+ flags |= GPIOF_EXPORT_CHANGEABLE;
+
+ err = gpio_request_one(gpio->gpio, flags, name);
+ if (err)
+ goto err_prop;
+
+ err = gpio_export_link(&pdev->dev, name, gpio->gpio);
+ if (err)
+ goto err_gpio;
+
+ gpio->link = name;
+
+ return 0;
+
+err_gpio:
+ gpio_free(gpio->gpio);
+err_prop:
+ of_node_put(child);
+
+ return err;
+}
+
+static void gpio_switch_rem(struct device *dev,
+ struct gpio_switch_gpio_info *gpio)
+{
+ sysfs_remove_link(&dev->kobj, gpio->link);
+
+ gpio_unexport(gpio->gpio);
+
+ gpio_free(gpio->gpio);
+}
+
+static int gpio_switch_probe(struct platform_device *pdev)
+{
+ struct gpio_switch_gpio_info *gpios;
+ struct device_node *child;
+ struct device_node *np = pdev->dev.of_node;
+ int ret;
+ int i;
+
+ i = of_get_child_count(np);
+ if (i < 1)
+ return i;
+
+ gpi
Add support for monitoring gpio switches
This driver was written to expose a read only interface to a number of gpios on Chromebooks. These gpios are attached to signals which cause the firmware on Chromebooks to enter alternative modes of operation and/or control other device characteristics (such as write protection on flash devices). It was originally posted as "Add support for monitoring Chrome OS firmware signals". A request was made to make it more generic. In addition this patch series provides the required bindings for this to the peach-pi Chromebook. This is a new binding, but the driver is based (now some what loosely) on functionality in the kernel shipped on Chromebooks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Add support for monitoring gpio switches
On 04/12/15 18:57, Greg Kroah-Hartman wrote: On Fri, Dec 04, 2015 at 05:31:14PM +, Martyn Welch wrote: Select Chromebooks have gpio attached to switches used to cause the firmware to enter alternative modes of operation and/or control other device characteristics (such as write protection on flash devices). This patch adds a driver that exposes a read-only interface to allow these signals to be read from user space. This functionality has been generalised to provide support for any device with device tree support which needs to identify a gpio as being used for a specific task. Signed-off-by: Martyn Welch --- drivers/misc/Kconfig | 11 drivers/misc/Makefile | 1 + drivers/misc/gpio-switch.c | 160 + Why isn't this in drivers/gpio/ ? why make it a misc driver? I thought all the drivers in /drivers/gpio were gpio drivers, rather than users of the gpio framework. Is that not the case? Happy to move it if the consensus is that that's the correct place to put it. Martyn thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Device tree binding documentation for gpio-switch
On 07/12/15 17:37, Rob Herring wrote:
+Linus W
On Fri, Dec 04, 2015 at 05:31:13PM +, Martyn Welch wrote:
This patch adds documentation for the gpio-switch binding. This binding
provides a mechanism to bind named links to gpio, with the primary
purpose of enabling standardised access to switches that might be standard
across a group of devices but implemented differently on each device.
This is good and what I suggested, but it now makes me wonder if switch
is generic enough. This boils down to needing to expose single gpio
lines to userspace with a defined function/use. IIRC, there's been some
discussion about this before along with improving the userspace
interface for GPIO in general. So I'd like to get Linus' thoughts on
this.
No problem. Rename gpio-signal?
Signed-off-by: Martyn Welch
---
.../devicetree/bindings/misc/gpio-switch.txt | 47 ++
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/gpio-switch.txt
diff --git a/Documentation/devicetree/bindings/misc/gpio-switch.txt
b/Documentation/devicetree/bindings/misc/gpio-switch.txt
new file mode 100644
index 000..13528bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/gpio-switch.txt
@@ -0,0 +1,47 @@
+Device-Tree bindings for gpio attached switches.
+
+This provides a mechanism to provide a named link to specified gpios. This can
+be useful in instances such as when theres a need to monitor a switch, which is
+common across a family of devices, but attached to different gpios and even
+implemented in different ways on differnet devices.
+
+Required properties:
+ - compatible = "gpio-switch";
+
+Each signal is represented as a sub-node of "gpio-switch". The naming of
+sub-nodes is arbitrary.
+
+Required sub-node properties:
+
+ - label: Name to be given to gpio switch.
+ - gpios: OF device-tree gpio specification.
+
+Optional sub-node properties:
+
+ - read-only: Boolean flag to mark the gpio as read-only, i.e. the line
+ should not be driven by the host.
In terms a a switch use, allowing driving it would be an override of the
switch. Is that the idea here?
Yeah - since it had become a lot more generic and a lot of
switches/signals would probably be implemented with a pull-up resistor
of something like that, it seemed to make sense to allow them to be
driven as well.
+
+Example nodes:
+
+gpio-switch {
+compatible = "gpio-switch";
Both from a binding and driver perspective, there is no point in
grouping these. Each node can simply have this compatible string.
True. I did it this way as this is how gpio-keys is implemented. OK,
that has one optional parameter (autorepeat) for the block and this has
none. Though I can also see that these probably have less in common than
the individual lines used in gpio-keys.
+
+write-protect {
+label = "write-protect";
+gpios = <&gpx3 0 GPIO_ACTIVE_LOW>;
+read-only;
+};
+
+developer-switch {
+label = "developer-switch";
+gpios = <&gpx1 3 GPIO_ACTIVE_HIGH>;
+read-only;
+};
+
+recovery-switch {
+label = "recovery-switch";
+gpios = <&gpx0 7 GPIO_ACTIVE_LOW>;
+read-only;
+};
+};
+
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Add support for monitoring gpio switches
On 11/12/15 09:08, Linus Walleij wrote: On Fri, Dec 4, 2015 at 6:31 PM, Martyn Welch wrote: Select Chromebooks have gpio attached to switches used to cause the firmware to enter alternative modes of operation and/or control other device characteristics (such as write protection on flash devices). This patch adds a driver that exposes a read-only interface to allow these signals to be read from user space. This functionality has been generalised to provide support for any device with device tree support which needs to identify a gpio as being used for a specific task. Signed-off-by: Martyn Welch If you want to do this thing, also propose a device tree binding document for "gpio-switch". But first (from Documentation/gpio/drivers-on-gpio.txt): - gpio-keys: drivers/input/keyboard/gpio_keys.c is used when your GPIO line can generate interrupts in response to a key press. Also supports debounce. This one generates input events from gpio. I'm not looking to generate events. - gpio-keys-polled: drivers/input/keyboard/gpio_keys_polled.c is used when your GPIO line cannot generate interrupts, so it needs to be periodically polled by a timer. Ditto (but using a polled mechanism rather than interrupts) - extcon-gpio: drivers/extcon/extcon-gpio.c is used when you need to read an external connector status, such as a headset line for an audio driver or an HDMI connector. It will provide a better userspace sysfs interface than GPIO. This appears to be exclusively for monitoring insertion events, or am I missing something? So you mean none of these apply for this case? No, I'm looking for a mechanism to identify GPIO as connected to a specific signal, which is provided across multiple devices, but which might be implemented subtly differently on different platforms (i.e. active high/low) and on different GPIO lines. Second: what you want to do is export a number of GPIOs with certain names to userspace. This is something very generic and should be implemented as such, not as something Chromebook-specific. I'd agree that my first implementation was ChromeBook specific, but I'm fairly sure that my last attempt wasn't. I've mentioned ChromeBooks as an example of an existing use case. Patches like that has however already been suggested, and I have NACKed them because the GPIO sysfs ABI is insane, and that is why I am refactoring the world to create a proper chardev ABI for GPIO instead. See: http://marc.info/?l=linux-gpio&m=144550276512673&w=2 I can certainly understand the rationale for the changes that you are proposing, though do worry that it does make it a bit tougher to use from scripting languages. I see that the question of how to provide functionality equivalent to the above was raised and no answer was forthcoming. Is there a plan for supporting the identification of a GPIO line serving a specific purpose? What is the status of the mentioned patch series? Martyn So for the moment, NACK on this, please participate in creating the *right* ABI for GPIO instead of trying to shoehorn stuff into the dying sysfs ABI. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] Device tree binding documentation for chromeos-firmware
This patch adds documentation for the chromeos-firmware binding.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: devicet...@vger.kernel.org
Signed-off-by: Martyn Welch
---
.../devicetree/bindings/misc/chromeos-firmware.txt | 27 ++
1 file changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/chromeos-firmware.txt
diff --git a/Documentation/devicetree/bindings/misc/chromeos-firmware.txt
b/Documentation/devicetree/bindings/misc/chromeos-firmware.txt
new file mode 100644
index 000..8240611
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/chromeos-firmware.txt
@@ -0,0 +1,27 @@
+Device-Tree bindings for chromeos-firmware.c.
+
+Required properties:
+ - compatible = "google,gpio-firmware";
+
+Each signal is represented as a sub-node of "chromeos_firmware":
+Subnode properties:
+
+ - gpios: OF device-tree gpio specification.
+
+Example nodes:
+
+ chromeos_firmware {
+ compatible = "google,gpio-firmware";
+
+ write-protect {
+ gpios = <&gpx3 0 GPIO_ACTIVE_LOW>;
+ };
+
+ developer-switch {
+ gpios = <&gpx1 3 GPIO_ACTIVE_HIGH>;
+ };
+
+ recovery-switch {
+ gpios = <&gpx0 7 GPIO_ACTIVE_LOW>;
+ };
+ };
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] Add support for monitoring Chrome OS firmware signals
Select Chromebooks have gpio attached to signals used to cause the firmware
to enter alternative modes of operation and/or control other device
characteristics (such as write protection on flash devices). This patch
adds a driver that exposes a read-only interface to allow these signals to
be read from user space.
Signed-off-by: Martyn Welch
---
drivers/platform/chrome/Kconfig | 13 +++
drivers/platform/chrome/Makefile| 1 +
drivers/platform/chrome/chromeos_firmware.c | 156
3 files changed, 170 insertions(+)
create mode 100644 drivers/platform/chrome/chromeos_firmware.c
diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig
index d03df4a..d55ceef 100644
--- a/drivers/platform/chrome/Kconfig
+++ b/drivers/platform/chrome/Kconfig
@@ -38,6 +38,19 @@ config CHROMEOS_PSTORE
If you have a supported Chromebook, choose Y or M here.
The module will be called chromeos_pstore.
+config CHROMEOS_FIRMWARE
+ tristate "Chrome OS firmware signal monitoring"
+ depends on GPIO_SYSFS
+ ---help---
+Many chromebooks have gpio attached to signals used to cause the
+firmware to enter alternative modes of operation and/or control other
+device characteristics (such as write protection on flash devices).
+This driver exposes a read-only interface to allow these signals to be
+read from user space.
+
+If you have a supported Chromebook, choose Y or M here.
+The module will be called chromeos_firmware.
+
config CROS_EC_CHARDEV
tristate "Chrome OS Embedded Controller userspace device interface"
depends on MFD_CROS_EC
diff --git a/drivers/platform/chrome/Makefile b/drivers/platform/chrome/Makefile
index bc498bd..2453adf 100644
--- a/drivers/platform/chrome/Makefile
+++ b/drivers/platform/chrome/Makefile
@@ -1,6 +1,7 @@
obj-$(CONFIG_CHROMEOS_LAPTOP) += chromeos_laptop.o
obj-$(CONFIG_CHROMEOS_PSTORE) += chromeos_pstore.o
+obj-$(CONFIG_CHROMEOS_FIRMWARE)+= chromeos_firmware.o
cros_ec_devs-objs := cros_ec_dev.o cros_ec_sysfs.o \
cros_ec_lightbar.o cros_ec_vbc.o
obj-$(CONFIG_CROS_EC_CHARDEV) += cros_ec_devs.o
diff --git a/drivers/platform/chrome/chromeos_firmware.c
b/drivers/platform/chrome/chromeos_firmware.c
new file mode 100644
index 000..ab8540a
--- /dev/null
+++ b/drivers/platform/chrome/chromeos_firmware.c
@@ -0,0 +1,156 @@
+/*
+ * Copyright (C) 2015 Collabora Ltd.
+ *
+ * based on vendor driver,
+ *
+ * Copyright (C) 2011 The Chromium OS Authors
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct chromeos_firmware_data {
+ int wp;
+ int rec;
+ int dev;
+};
+
+static int dt_gpio_init(struct platform_device *pdev, const char *of_list_name,
+ const char *gpio_desc_name, const char *sysfs_name,
+ int *gpio)
+{
+ int err;
+ enum of_gpio_flags of_flags;
+ unsigned long flags = GPIOF_DIR_IN | GPIOF_EXPORT;
+ struct device_node *np = pdev->dev.of_node;
+ struct device_node *cnp;
+
+ cnp = of_get_child_by_name(np, of_list_name);
+ if (!cnp)
+ /*
+* We don't necessarily expect to find all of the devices, so
+* return without generating an error.
+*/
+ return 0;
+
+ *gpio = of_get_named_gpio_flags(cnp, "gpios", 0, &of_flags);
+ if (!gpio_is_valid(*gpio)) {
+ err = -EINVAL;
+ goto err_prop;
+ }
+
+ if (of_flags & OF_GPIO_ACTIVE_LOW)
+ flags |= GPIOF_ACTIVE_LOW;
+
+ err = gpio_request_one(*gpio, flags, gpio_desc_name);
+ if (err)
+ goto err_prop;
+
+ err = gpio_export_link(&pdev->dev, sysfs_name, *gpio);
+ if (err)
+ goto err_gpio;
+
+ return 0;
+
+err_gpio:
+ gpio_free(*gpio);
+err_prop:
+ of_node_put(cnp);
+
+ return err;
+}
+
+static void chromeos_firmware_rem(int gpio)
+{
+ gpio_unexport(gpio);
+
+ gpio_free(gpio);
+}
+
+static int chromeos_firmware_probe(struct platform_device *pdev)
+{
+ int err;
+ struct chromeos_firmware_data *gpios;
+
+ gpios = devm_kmalloc(&pdev->dev, sizeof(gpios), GFP_KERNEL);
+
[PATCH 3/3] Addition of binding for firmware signals on peach-pi
The peach pi has a GPIO connected to the firmware write protect, developer
mode and recovery mode lines. This patch adds the required nodes to the
device tree to configure the pinmuxing and allow these to be read from
user space.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Russell King
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Signed-off-by: Martyn Welch
---
arch/arm/boot/dts/exynos5800-peach-pi.dts | 40 +++
1 file changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 49a4f43..485c18f 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -53,6 +53,25 @@
};
};
+ chromeos-firmware {
+ compatible = "google,gpio-firmware";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&wp_gpio &dev_mode &rec_mode>;
+
+ write-protect {
+ gpios = <&gpx3 0 GPIO_ACTIVE_LOW>;
+ };
+
+ developer-switch {
+ gpios = <&gpx1 3 GPIO_ACTIVE_HIGH>;
+ };
+
+ recovery-switch {
+ gpios = <&gpx0 7 GPIO_ACTIVE_LOW>;
+ };
+ };
+
gpio-keys {
compatible = "gpio-keys";
@@ -731,6 +750,13 @@
samsung,pin-val = <0>;
};
+ rec_mode: rec-mode {
+ samsung,pins = "gpx0-7";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
tpm_irq: tpm-irq {
samsung,pins = "gpx1-0";
samsung,pin-function = <0>;
@@ -752,6 +778,13 @@
samsung,pin-drv = <0>;
};
+ dev_mode: dev-mode {
+ samsung,pins = "gpx1-3";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
ec_irq: ec-irq {
samsung,pins = "gpx1-5";
samsung,pin-function = <0>;
@@ -773,6 +806,13 @@
samsung,pin-drv = <0>;
};
+ wp_gpio: wp_gpio {
+ samsung,pins = "gpx3-0";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
max77802_irq: max77802-irq {
samsung,pins = "gpx3-1";
samsung,pin-function = <0>;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Add support for Chrome OS firmware signals
Some Chromebooks have gpio attached to signals used to cause the firmware to enter alternative modes of operation and/or control other device characteristics (such as write protection on flash devices). This patch adds a driver that exposes a read-only interface to allow these signals to be read from user space. In addition this patch series provides the required bindings for this to the peach-pi Chromebook. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] Add support for monitoring Chrome OS firmware signals
Select Chromebooks have gpio attached to signals used to cause the firmware
to enter alternative modes of operation and/or control other device
characteristics (such as write protection on flash devices). This patch
adds a driver that exposes a read-only interface to allow these signals to
be read from user space.
Signed-off-by: Martyn Welch
---
v2:
- Added missing call to remove sysfs link.
drivers/platform/chrome/Kconfig | 13 +++
drivers/platform/chrome/Makefile| 1 +
drivers/platform/chrome/chromeos_firmware.c | 166
3 files changed, 180 insertions(+)
create mode 100644 drivers/platform/chrome/chromeos_firmware.c
diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig
index d03df4a..d55ceef 100644
--- a/drivers/platform/chrome/Kconfig
+++ b/drivers/platform/chrome/Kconfig
@@ -38,6 +38,19 @@ config CHROMEOS_PSTORE
If you have a supported Chromebook, choose Y or M here.
The module will be called chromeos_pstore.
+config CHROMEOS_FIRMWARE
+ tristate "Chrome OS firmware signal monitoring"
+ depends on GPIO_SYSFS
+ ---help---
+Many chromebooks have gpio attached to signals used to cause the
+firmware to enter alternative modes of operation and/or control other
+device characteristics (such as write protection on flash devices).
+This driver exposes a read-only interface to allow these signals to be
+read from user space.
+
+If you have a supported Chromebook, choose Y or M here.
+The module will be called chromeos_firmware.
+
config CROS_EC_CHARDEV
tristate "Chrome OS Embedded Controller userspace device interface"
depends on MFD_CROS_EC
diff --git a/drivers/platform/chrome/Makefile b/drivers/platform/chrome/Makefile
index bc498bd..2453adf 100644
--- a/drivers/platform/chrome/Makefile
+++ b/drivers/platform/chrome/Makefile
@@ -1,6 +1,7 @@
obj-$(CONFIG_CHROMEOS_LAPTOP) += chromeos_laptop.o
obj-$(CONFIG_CHROMEOS_PSTORE) += chromeos_pstore.o
+obj-$(CONFIG_CHROMEOS_FIRMWARE)+= chromeos_firmware.o
cros_ec_devs-objs := cros_ec_dev.o cros_ec_sysfs.o \
cros_ec_lightbar.o cros_ec_vbc.o
obj-$(CONFIG_CROS_EC_CHARDEV) += cros_ec_devs.o
diff --git a/drivers/platform/chrome/chromeos_firmware.c
b/drivers/platform/chrome/chromeos_firmware.c
new file mode 100644
index 000..a08cb57
--- /dev/null
+++ b/drivers/platform/chrome/chromeos_firmware.c
@@ -0,0 +1,166 @@
+/*
+ * Copyright (C) 2015 Collabora Ltd.
+ *
+ * based on vendor driver,
+ *
+ * Copyright (C) 2011 The Chromium OS Authors
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct chromeos_firmware_gpio_info {
+ int gpio;
+ const char *link;
+};
+
+struct chromeos_firmware_data {
+ struct chromeos_firmware_gpio_info wp;
+ struct chromeos_firmware_gpio_info rec;
+ struct chromeos_firmware_gpio_info dev;
+};
+
+static int dt_gpio_init(struct platform_device *pdev, const char *of_list_name,
+ const char *gpio_desc_name, const char *sysfs_name,
+ struct chromeos_firmware_gpio_info *gpio)
+{
+ int err;
+ enum of_gpio_flags of_flags;
+ unsigned long flags = GPIOF_DIR_IN | GPIOF_EXPORT;
+ struct device_node *np = pdev->dev.of_node;
+ struct device_node *cnp;
+
+ cnp = of_get_child_by_name(np, of_list_name);
+ if (!cnp)
+ /*
+* We don't necessarily expect to find all of the devices, so
+* return without generating an error.
+*/
+ return 0;
+
+ gpio->gpio = of_get_named_gpio_flags(cnp, "gpios", 0, &of_flags);
+ if (!gpio_is_valid(gpio->gpio)) {
+ err = -EINVAL;
+ goto err_prop;
+ }
+
+ if (of_flags & OF_GPIO_ACTIVE_LOW)
+ flags |= GPIOF_ACTIVE_LOW;
+
+ err = gpio_request_one(gpio->gpio, flags, gpio_desc_name);
+ if (err)
+ goto err_prop;
+
+ err = gpio_export_link(&pdev->dev, sysfs_name, gpio->gpio);
+ if (err)
+ goto err_gpio;
+
+ gpio->link = sysfs_name;
+
+ return 0;
+
+err_gpio:
+ gpio_free(gpio->gpio);
+err_prop:
+ of_node_put(cnp);
+
+
Re: [PATCH 3/3] Addition of binding for firmware signals on peach-pi
On 01/12/15 23:51, Krzysztof Kozlowski wrote:
On 02.12.2015 04:12, Martyn Welch wrote:
The peach pi has a GPIO connected to the firmware write protect, developer
mode and recovery mode lines. This patch adds the required nodes to the
device tree to configure the pinmuxing and allow these to be read from
user space.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Russell King
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Signed-off-by: Martyn Welch
---
arch/arm/boot/dts/exynos5800-peach-pi.dts | 40 +++
1 file changed, 40 insertions(+)
Hi,
Thanks for the patch.
Few points from my side:
1. Please add a prefix to the subject: "ARM: dts:".
Ok, sorry.
2. There is no need of such huge CC-list in the body of commit. This
CC-list comes from get_maintainer so there is no benefit of duplicating
it here. The CC is usually used to notify other people who might be
interested but get_maintainer does not point them.
Ok, yes these were pulled from get_maintainer.
3. I received only this third patch. I did not receive cover letter
explaining possible dependencies so I am not sure how to deal with the
patch. It looks like there are no dependencies... but maybe there are?
Is this is a new binding or no? Please provide a cover letter (if it
exists already be sure to send it to all interested parties) or send
entire patchset so the big picture could be seen.
I'll make sure I do that next time.
The cover letter read:
Some Chromebooks have gpio attached to signals used to cause the
firmware to enter alternative modes of operation and/or control other
device characteristics (such as write protection on flash devices). This
patch adds a driver that exposes a read-only interface to allow these
signals to be read from user space.
In addition this patch series provides the required bindings for this to
the peach-pi Chromebook.
This is a new binding, but the driver is based on functionality in the
kernel shipped on Chromebooks. The binding has been modified based on
the form of existing bindings in the mainline kernel.
Does that help?
Martyn
The patch itself looks good but I'll wait with a review tag for #3.
Best regards,
Krzysztof
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 49a4f43..485c18f 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -53,6 +53,25 @@
};
};
+ chromeos-firmware {
+ compatible = "google,gpio-firmware";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&wp_gpio &dev_mode &rec_mode>;
+
+ write-protect {
+ gpios = <&gpx3 0 GPIO_ACTIVE_LOW>;
+ };
+
+ developer-switch {
+ gpios = <&gpx1 3 GPIO_ACTIVE_HIGH>;
+ };
+
+ recovery-switch {
+ gpios = <&gpx0 7 GPIO_ACTIVE_LOW>;
+ };
+ };
+
gpio-keys {
compatible = "gpio-keys";
@@ -731,6 +750,13 @@
samsung,pin-val = <0>;
};
+ rec_mode: rec-mode {
+ samsung,pins = "gpx0-7";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
tpm_irq: tpm-irq {
samsung,pins = "gpx1-0";
samsung,pin-function = <0>;
@@ -752,6 +778,13 @@
samsung,pin-drv = <0>;
};
+ dev_mode: dev-mode {
+ samsung,pins = "gpx1-3";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
ec_irq: ec-irq {
samsung,pins = "gpx1-5";
samsung,pin-function = <0>;
@@ -773,6 +806,13 @@
samsung,pin-drv = <0>;
};
+ wp_gpio: wp_gpio {
+ samsung,pins = "gpx3-0";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
max77802_irq: max77802-irq {
samsung,pins = "gpx3-1";
samsung,pin-function = <0>;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Add support for monitoring Chrome OS firmware signals
On 02/12/15 06:08, Jeremiah Mahler wrote:
Martyn,
On Tue, Dec 01, 2015 at 08:19:46PM +, Martyn Welch wrote:
Select Chromebooks have gpio attached to signals used to cause the firmware
to enter alternative modes of operation and/or control other device
[...]
+
+static int chromeos_firmware_probe(struct platform_device *pdev)
+{
+ int err;
+ struct chromeos_firmware_data *gpios;
+
+ gpios = devm_kmalloc(&pdev->dev, sizeof(gpios), GFP_KERNEL);
Should this be 'sizeof(*gpios)' so it allocates enough room for the
entire struct instead of just the pointer?
Yes, you're right, it should.
Martyn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] Add support for monitoring Chrome OS firmware signals
Select Chromebooks have gpio attached to signals used to cause the firmware
to enter alternative modes of operation and/or control other device
characteristics (such as write protection on flash devices). This patch
adds a driver that exposes a read-only interface to allow these signals to
be read from user space.
Cc: Jeremiah Mahler
Signed-off-by: Martyn Welch
---
v2:
- Added missing call to remove sysfs link.
v3:
- Correct malloc sizeof() usage.
drivers/platform/chrome/Kconfig | 13 +++
drivers/platform/chrome/Makefile| 1 +
drivers/platform/chrome/chromeos_firmware.c | 166
3 files changed, 180 insertions(+)
create mode 100644 drivers/platform/chrome/chromeos_firmware.c
diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig
index d03df4a..d55ceef 100644
--- a/drivers/platform/chrome/Kconfig
+++ b/drivers/platform/chrome/Kconfig
@@ -38,6 +38,19 @@ config CHROMEOS_PSTORE
If you have a supported Chromebook, choose Y or M here.
The module will be called chromeos_pstore.
+config CHROMEOS_FIRMWARE
+ tristate "Chrome OS firmware signal monitoring"
+ depends on GPIO_SYSFS
+ ---help---
+Many chromebooks have gpio attached to signals used to cause the
+firmware to enter alternative modes of operation and/or control other
+device characteristics (such as write protection on flash devices).
+This driver exposes a read-only interface to allow these signals to be
+read from user space.
+
+If you have a supported Chromebook, choose Y or M here.
+The module will be called chromeos_firmware.
+
config CROS_EC_CHARDEV
tristate "Chrome OS Embedded Controller userspace device interface"
depends on MFD_CROS_EC
diff --git a/drivers/platform/chrome/Makefile b/drivers/platform/chrome/Makefile
index bc498bd..2453adf 100644
--- a/drivers/platform/chrome/Makefile
+++ b/drivers/platform/chrome/Makefile
@@ -1,6 +1,7 @@
obj-$(CONFIG_CHROMEOS_LAPTOP) += chromeos_laptop.o
obj-$(CONFIG_CHROMEOS_PSTORE) += chromeos_pstore.o
+obj-$(CONFIG_CHROMEOS_FIRMWARE)+= chromeos_firmware.o
cros_ec_devs-objs := cros_ec_dev.o cros_ec_sysfs.o \
cros_ec_lightbar.o cros_ec_vbc.o
obj-$(CONFIG_CROS_EC_CHARDEV) += cros_ec_devs.o
diff --git a/drivers/platform/chrome/chromeos_firmware.c
b/drivers/platform/chrome/chromeos_firmware.c
new file mode 100644
index 000..5c2c96a
--- /dev/null
+++ b/drivers/platform/chrome/chromeos_firmware.c
@@ -0,0 +1,166 @@
+/*
+ * Copyright (C) 2015 Collabora Ltd.
+ *
+ * based on vendor driver,
+ *
+ * Copyright (C) 2011 The Chromium OS Authors
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct chromeos_firmware_gpio_info {
+ int gpio;
+ const char *link;
+};
+
+struct chromeos_firmware_data {
+ struct chromeos_firmware_gpio_info wp;
+ struct chromeos_firmware_gpio_info rec;
+ struct chromeos_firmware_gpio_info dev;
+};
+
+static int dt_gpio_init(struct platform_device *pdev, const char *of_list_name,
+ const char *gpio_desc_name, const char *sysfs_name,
+ struct chromeos_firmware_gpio_info *gpio)
+{
+ int err;
+ enum of_gpio_flags of_flags;
+ unsigned long flags = GPIOF_DIR_IN | GPIOF_EXPORT;
+ struct device_node *np = pdev->dev.of_node;
+ struct device_node *cnp;
+
+ cnp = of_get_child_by_name(np, of_list_name);
+ if (!cnp)
+ /*
+* We don't necessarily expect to find all of the devices, so
+* return without generating an error.
+*/
+ return 0;
+
+ gpio->gpio = of_get_named_gpio_flags(cnp, "gpios", 0, &of_flags);
+ if (!gpio_is_valid(gpio->gpio)) {
+ err = -EINVAL;
+ goto err_prop;
+ }
+
+ if (of_flags & OF_GPIO_ACTIVE_LOW)
+ flags |= GPIOF_ACTIVE_LOW;
+
+ err = gpio_request_one(gpio->gpio, flags, gpio_desc_name);
+ if (err)
+ goto err_prop;
+
+ err = gpio_export_link(&pdev->dev, sysfs_name, gpio->gpio);
+ if (err)
+ goto err_gpio;
+
+ gpio->link = sysfs_name;
+
+ return 0;
+
+err_gpio:
+ gpio_free(gp
Re: [PATCH 1/3] Device tree binding documentation for chromeos-firmware
On 02/12/15 15:15, Rob Herring wrote:
On Tue, Dec 01, 2015 at 07:12:49PM +, Martyn Welch wrote:
This patch adds documentation for the chromeos-firmware binding.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: devicet...@vger.kernel.org
Signed-off-by: Martyn Welch
---
.../devicetree/bindings/misc/chromeos-firmware.txt | 27 ++
bindings/firmware/ please.
OK.
1 file changed, 27 insertions(+)
create mode 100644
Documentation/devicetree/bindings/misc/chromeos-firmware.txt
diff --git a/Documentation/devicetree/bindings/misc/chromeos-firmware.txt
b/Documentation/devicetree/bindings/misc/chromeos-firmware.txt
new file mode 100644
index 000..8240611
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/chromeos-firmware.txt
@@ -0,0 +1,27 @@
+Device-Tree bindings for chromeos-firmware.c.
Perhaps a bit more description what this is.
What aspect of this is firmware? How does this relate to the EC?
With respect to write-protect, this line is the write protection for the
flash which holds the bootloader.
For the developer-switch and recovery-switch, I understand that pulling
these lines low result in the stock firmware forcing the device to boot
into developer mode and recovery mode respectively. The device I have no
longer runs the stock firmware, so I'm not able to confirm this, though
I am able to drive these lines.
As far as I'm aware, none of these are related to the operation of the EC.
Will update the binding documentation.
+
+Required properties:
+ - compatible = "google,gpio-firmware";
No versions?
I'm not aware of any and would rather not start inventing ones that
aren't already there.
+
+Each signal is represented as a sub-node of "chromeos_firmware":
+Subnode properties:
+
+ - gpios: OF device-tree gpio specification.
+
+Example nodes:
+
+ chromeos_firmware {
This should go under /firmware
Ok, will do.
+ compatible = "google,gpio-firmware";
+
+ write-protect {
You need to define what are valid sub nodes. The example is not
documentation.
Ok
+ gpios = <&gpx3 0 GPIO_ACTIVE_LOW>;
+ };
+
+ developer-switch {
+ gpios = <&gpx1 3 GPIO_ACTIVE_HIGH>;
+ };
+
+ recovery-switch {
+ gpios = <&gpx0 7 GPIO_ACTIVE_LOW>;
+ };
+ };
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Device tree binding documentation for chromeos-firmware
On 02/12/15 18:44, Rob Herring wrote: On Wed, Dec 2, 2015 at 10:49 AM, Martyn Welch wrote: On 02/12/15 15:15, Rob Herring wrote: On Tue, Dec 01, 2015 at 07:12:49PM +, Martyn Welch wrote: This patch adds documentation for the chromeos-firmware binding. Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Cc: devicet...@vger.kernel.org Signed-off-by: Martyn Welch --- .../devicetree/bindings/misc/chromeos-firmware.txt | 27 ++ bindings/firmware/ please. OK. 1 file changed, 27 insertions(+) create mode 100644 Documentation/devicetree/bindings/misc/chromeos-firmware.txt diff --git a/Documentation/devicetree/bindings/misc/chromeos-firmware.txt b/Documentation/devicetree/bindings/misc/chromeos-firmware.txt new file mode 100644 index 000..8240611 --- /dev/null +++ b/Documentation/devicetree/bindings/misc/chromeos-firmware.txt @@ -0,0 +1,27 @@ +Device-Tree bindings for chromeos-firmware.c. Perhaps a bit more description what this is. What aspect of this is firmware? How does this relate to the EC? With respect to write-protect, this line is the write protection for the flash which holds the bootloader. What is driving the write-protect? Are trying to assign ownership of the SOC GPIOs to the bootloader/firmware? If so, I think this is all wrong. The lines are typically driven by a debugging board plugged into a socket on the Chromebooks motherboard, not by the device it's self. The driver exposes a read-only interface to these signals. Martyn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Device tree binding documentation for chromeos-firmware
On 02/12/15 15:15, Rob Herring wrote:
On Tue, Dec 01, 2015 at 07:12:49PM +, Martyn Welch wrote:
This patch adds documentation for the chromeos-firmware binding.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: devicet...@vger.kernel.org
Signed-off-by: Martyn Welch
---
.../devicetree/bindings/misc/chromeos-firmware.txt | 27 ++
bindings/firmware/ please.
1 file changed, 27 insertions(+)
create mode 100644
Documentation/devicetree/bindings/misc/chromeos-firmware.txt
diff --git a/Documentation/devicetree/bindings/misc/chromeos-firmware.txt
b/Documentation/devicetree/bindings/misc/chromeos-firmware.txt
new file mode 100644
index 000..8240611
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/chromeos-firmware.txt
@@ -0,0 +1,27 @@
+
+Each signal is represented as a sub-node of "chromeos_firmware":
+Subnode properties:
+
+ - gpios: OF device-tree gpio specification.
+
+Example nodes:
+
+ chromeos_firmware {
This should go under /firmware
I've changed this to be:
firmware {
chromeos {
...
};
];
Which I generally accept (assuming this is considered a part of the
firmware) as a better way to represent this in the device tree, however
this has the nasty side effect of causing the device tree parsing to
avoid parsing the chromeos child and seeing it's compatible property (as
the firmware node isn't a bus), resulting in the probe routine not being
called.
If I add a 'compatible = "simple-bus"' property to the firmware node it
works, but this doesn't seem quite right as I believe "simple-bus" is
defined as a "simple memory mapped bus".
I /could/ rewrite the initialisation to call of_find_compatible_node(),
but this seems rather hacky and inefficient. I can think of 2 other ways
this could be resolved:
(1) As this is only tangentially related to firmware, I rename it
something like "chromeos-signals" and make it it's own node. In essence
this driver provides a mechanism built on top of specific GPIO (ala
gpio-keys seems to be, after-all this has a similar use of resources to
that).
(2) Add a compatible string something like 'compatible="logical-group";'
to the firmware node and add that too the bus matching logic. This would
have the advantage of solving this in the general case (I guess there
are other instances where a grouping of things more logically rather
than physically connected would ideally be grouped together), though I
expect there may be some strong views regarding this approach.
Would either of those be acceptable or is there a better way of
resolving this that I've missed?
Martyn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Device tree binding documentation for chromeos-firmware
On 03/12/15 15:08, Rob Herring wrote:
On Thu, Dec 3, 2015 at 4:14 AM, Martyn Welch
wrote:
On 02/12/15 15:15, Rob Herring wrote:
On Tue, Dec 01, 2015 at 07:12:49PM +, Martyn Welch wrote:
This patch adds documentation for the chromeos-firmware binding.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: devicet...@vger.kernel.org
Signed-off-by: Martyn Welch
---
.../devicetree/bindings/misc/chromeos-firmware.txt | 27
++
bindings/firmware/ please.
1 file changed, 27 insertions(+)
create mode 100644
Documentation/devicetree/bindings/misc/chromeos-firmware.txt
diff --git a/Documentation/devicetree/bindings/misc/chromeos-firmware.txt
b/Documentation/devicetree/bindings/misc/chromeos-firmware.txt
new file mode 100644
index 000..8240611
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/chromeos-firmware.txt
@@ -0,0 +1,27 @@
+
+Each signal is represented as a sub-node of "chromeos_firmware":
+Subnode properties:
+
+ - gpios: OF device-tree gpio specification.
+
+Example nodes:
+
+ chromeos_firmware {
This should go under /firmware
I've changed this to be:
firmware {
chromeos {
...
};
];
Which I generally accept (assuming this is considered a part of the
firmware) as a better way to represent this in the device tree, however this
has the nasty side effect of causing the device tree parsing to avoid
parsing the chromeos child and seeing it's compatible property (as the
firmware node isn't a bus), resulting in the probe routine not being called.
If I add a 'compatible = "simple-bus"' property to the firmware node it
works, but this doesn't seem quite right as I believe "simple-bus" is
defined as a "simple memory mapped bus".
I /could/ rewrite the initialisation to call of_find_compatible_node(), but
this seems rather hacky and inefficient. I can think of 2 other ways this
could be resolved:
(1) As this is only tangentially related to firmware, I rename it something
like "chromeos-signals" and make it it's own node. In essence this driver
provides a mechanism built on top of specific GPIO (ala gpio-keys seems to
be, after-all this has a similar use of resources to that).
I'm starting to fail to understand the relationship to firmware here...
gpio-keys are at least a thing (being a key or set of keys). Your
grouping is a rather random collection of GPIOs. Maybe you need
"gpio-switch" binding and then the function would be "label" property.
So, something like this:
gpio-switch {
compatible = "gpio-switch";
pinctrl-names = "default";
pinctrl-0 = <&wp_gpio &dev_mode &rec_mode>;
write-protect {
label = "write-protect";
gpios = <&gpx3 0 GPIO_ACTIVE_LOW>;
read-only;
};
developer-switch {
label = "developer-switch";
gpios = <&gpx1 3 GPIO_ACTIVE_HIGH>;
read-only;
};
recovery-switch {
label = "recovery-switch";
gpios = <&gpx0 7 GPIO_ACTIVE_LOW>;
read-only;
};
};
(Making it much more generic in the process.)
(2) Add a compatible string something like 'compatible="logical-group";' to
the firmware node and add that too the bus matching logic. This would have
the advantage of solving this in the general case (I guess there are other
instances where a grouping of things more logically rather than physically
connected would ideally be grouped together), though I expect there may be
some strong views regarding this approach.
Why do you need them grouped?
That's effectively what is achieved by putting this (and I assume
anything else considered "firmware" under a firmware node isn't it? (or
and I miss-understanding your request?)
I think it is a moot point, I'll rework as you've suggested.
Martyn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Generic VME UIO driver
On 08/07/15 16:02, Dmitry Kalinkin wrote: On 08 Jul 2015, at 16:22, Martyn Welch wrote: On 06/07/15 18:24, Dmitry Kalinkin wrote: Some functionality was dropped as it was not good practice (such as receiving VME interrupts in user space, it's not really doable if the slave card is Release On Register Access rather than Release on Acknowledge), Didn't know about RORA. I wonder how different this is compared to the PCI bus case. Little I suspect. What it does mean is that there's no generic mechanism for clearing down an interrupt, so a device specific interrupt routine is required, which needs to be in kernel space. Yet PCI somehow managed to settle with UIO. "If, on the other hand, your hardware needs some action to be performed after each interrupt, then you must do it in your kernel module." https://www.kernel.org/doc/htmldocs/uio-howto/adding_irq_handler.html Now imagine I am working with a board using vme_user API and I need to implement interrupts. The PCI case teaches me that I need to write a board specific UIO driver. My board is ROAK and allows to configure it's interrupt to any level and any status/id. So I only use a standard vme_irq_request API that generates IACK cycle for me automatically. I also don’t want to limit my end user with a choice of interrupt level and status/id and so I make it configurable. In the end I’ve got a very generic ROAK device driver. What did I do wrong? Nothing by the sounds of it. If you have ROAK hardware, life is a lot simpler. Martyn Cheers, Dmitry -- Martyn Welch (Lead Software Engineer) | Registered in England and Wales GE Intelligent Platforms | (3828642) at 100 Barbirolli Square T +44(0)1327322748 | Manchester, M2 3AB E martyn.we...@ge.com | VAT:GB 927559189 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Rename "trigger" reset reason "hw watchdog"
The Zodiac watchdog is implemented on a microcontoller. The reset reason
currently labelled "trigger" is not to detect when the watchdog has
triggered (as had been initially understood and suggested by the naming),
but to inform the reader that the watchdog, which in fact has it's own
hardware watchdog, has been reset because the hardware watchdog has
triggered. Renaming to "hw watchdog".
Signed-off-by: Martyn Welch
---
drivers/watchdog/ziirave_wdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/ziirave_wdt.c b/drivers/watchdog/ziirave_wdt.c
index 0c7cb73..cbe373de 100644
--- a/drivers/watchdog/ziirave_wdt.c
+++ b/drivers/watchdog/ziirave_wdt.c
@@ -36,7 +36,7 @@
#define ZIIRAVE_STATE_OFF 0x1
#define ZIIRAVE_STATE_ON 0x2
-static char *ziirave_reasons[] = {"power cycle", "triggered", NULL, NULL,
+static char *ziirave_reasons[] = {"power cycle", "hw watchdog", NULL, NULL,
"host request", NULL, "illegal configuration",
"illegal instruction", "illegal trap",
"unknown"};
--
2.1.4
Re: [PATCH] staging: vme: fix bare use of 'unsigned'
On 31/03/16 23:53, Clifton Barnes wrote:
fix checkpatch.pl warning about 'Prefer 'unsigned int' to bare use of
'unsigned''
Signed-off-by: Clifton Barnes
Acked-by: Martyn Welch
Greg: Whilst this patch seems valid and compiles fine, I no longer have
access to the hardware for this driver. I'm aware this driver has been
in the staging tree for a rather long time. I will check to see if
there's any intention for further work to be done on this driver, if not
I guess we should be looking to delete it from the staging tree.
Martyn
---
drivers/staging/vme/devices/vme_pio2_gpio.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/vme/devices/vme_pio2_gpio.c
b/drivers/staging/vme/devices/vme_pio2_gpio.c
index df992c3..f52a9ed 100644
--- a/drivers/staging/vme/devices/vme_pio2_gpio.c
+++ b/drivers/staging/vme/devices/vme_pio2_gpio.c
@@ -97,7 +97,7 @@ static void pio2_gpio_set(struct gpio_chip *chip,
}
/* Directionality configured at board build - send appropriate response */
-static int pio2_gpio_dir_in(struct gpio_chip *chip, unsigned offset)
+static int pio2_gpio_dir_in(struct gpio_chip *chip, unsigned int offset)
{
int data;
struct pio2_card *card = gpio_to_pio2_card(chip);
@@ -116,7 +116,8 @@ static int pio2_gpio_dir_in(struct gpio_chip *chip,
unsigned offset)
}
/* Directionality configured at board build - send appropriate response */
-static int pio2_gpio_dir_out(struct gpio_chip *chip, unsigned offset, int
value)
+static int pio2_gpio_dir_out(struct gpio_chip *chip,
+unsigned int offset, int value)
{
int data;
struct pio2_card *card = gpio_to_pio2_card(chip);
[RFC 0/8] Add support for NVIDIA Tegra XUSB
This series is based on commits that can be found in the git tree here: https://github.com/thierryreding/linux/commits/staging/xhci I have included the patches I've used from that tree as patches 1-5. The above patches were submitted for review back in May: https://lkml.org/lkml/2015/5/4/574 The approach taken in these patches was deemed not appropriate (treating the XUSB as a MFD). In patch 6 I add the bindings based in those submitted for review here (with a few modifications currently required by the driver): https://www.spinics.net/lists/linux-usb/msg130940.html I have included my changes to the original patch series in patch 7. With these modifications the patch series builds and works, but is rather hacky. Devices for the mailbox driver and xHCI driver are now created in the xusb driver (still under the mfd directory for now - it will be moved before this series is submitted properly). As the child devices use infrastructure which expects the device to be associated with a of_node, it has been necessary to point the child device at the parents of_node where this is needed. This approach did not seem viable for the mailbox API, so to get that working the child device node was pointed to the parents of_node (in tegra_xusb_add_device). The unfortunate side effect of this is that upon device creation the parents probe routine gets called... Not good. Patch 8 attempts to resolve this. When passing the parents device node to the mailbox API, the mailbox's receive callback was raising errors as that function is looking for the drvdata stored in the child's device node, but getting the parents. This patch jumps though a few hoops to get to the child's device node. Unfortunately, whilst the receive callback seems to be getting the right drvdata, USB3 devices are being enumerated as USB2 devices rather than USB3 devices, so something is clearly not right. I'm posting these patches in the hope that someone can point me in the right direction. Is there a better approach I'm missing? Any ideas why devices aren't being enumerated as USB3? Martyn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 6/8] Adding binding for XUSB to tegra124 dtsi.
From: Martyn Welch
Adding the binding for the tegra xHCI controller implementation. In
addition to the dtsi entry, adding the defines needed to compile the
binding.
These bindings are based are in part based on the binding documentation
proposed here:
https://www.spinics.net/lists/linux-usb/msg130940.html
As you will see from the patch, I've had to add a few extra entries to get
the driver to load.
---
arch/arm/boot/dts/tegra124-nyan-big.dts | 32
arch/arm/boot/dts/tegra124-nyan-blaze.dts| 62
arch/arm/boot/dts/tegra124-nyan.dtsi | 47 +-
arch/arm/boot/dts/tegra124.dtsi | 3 +-
include/dt-bindings/pinctrl/pinctrl-tegra-xusb.h | 7 +++
5 files changed, 149 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/tegra124-nyan-big.dts
b/arch/arm/boot/dts/tegra124-nyan-big.dts
index 2d21253..a7b2838 100644
--- a/arch/arm/boot/dts/tegra124-nyan-big.dts
+++ b/arch/arm/boot/dts/tegra124-nyan-big.dts
@@ -26,6 +26,38 @@
nvidia,model = "GoogleNyanBig";
};
+
+ padctl@0,7009f000 {
+ pinctrl-0 = <&padctl_default>;
+ pinctrl-names = "default";
+
+ vbus-0-supply = <&vdd_usb1_vbus>;
+ vbus-1-supply = <&vdd_run_cam>;
+ vbus-2-supply = <&vdd_usb3_vbus>;
+
+ padctl_default: pinmux {
+ otg {
+ nvidia,lanes = "otg-0", "otg-1", "otg-2";
+ nvidia,function = "xusb";
+ };
+ usb3 {
+ nvidia,lanes = "pcie-0";
+ nvidia,function = "usb3";
+ nvidia,iddq = <0>;
+ nvidia,usb2-port = <0>;
+ nvidia,usb3-port = <0>;
+ };
+ usb3p1 {
+ nvidia,lanes = "pcie-1";
+ nvidia,function = "usb3";
+ nvidia,iddq = <0>;
+ nvidia,usb2-port = <2>;
+ nvidia,usb3-port = <1>;
+ };
+ };
+ };
+
+
pinmux@0,7868 {
pinctrl-names = "default";
pinctrl-0 = <&pinmux_default>;
diff --git a/arch/arm/boot/dts/tegra124-nyan-blaze.dts
b/arch/arm/boot/dts/tegra124-nyan-blaze.dts
index 0d30c51..cb2bacc 100644
--- a/arch/arm/boot/dts/tegra124-nyan-blaze.dts
+++ b/arch/arm/boot/dts/tegra124-nyan-blaze.dts
@@ -22,6 +22,68 @@
nvidia,model = "GoogleNyanBlaze";
};
+ padctl@0,7009f000 {
+ pinctrl-0 = <&padctl_default>;
+ pinctrl-names = "default";
+
+ vbus-0-supply = <&vdd_usb1_vbus>;
+ vbus-1-supply = <&vdd_run_cam>;
+ vbus-2-supply = <&vdd_usb3_vbus>;
+
+ phys {
+ pcie-0 {
+ status = "disabled";
+ };
+
+ sata-0 {
+ status = "disabled";
+ };
+
+ usb3-0 {
+ status = "ok";
+ nvidia,lanes = "pcie-0";
+ nvidia,function = "usb3";
+ nvidia,port = <0>;
+ };
+
+ usb3-1 {
+ status = "ok";
+ nvidia,lanes = "pcie-1";
+ nvidia,function = "usb3";
+ nvidia,port = <1>;
+ };
+
+ utmi-0 {
+ status = "ok";
+ };
+
+ utmi-1 {
+ status = "ok";
+ };
+
+ utmi-2 {
+ status = "ok";
+ };
+ };
+
+ padctl_default: pinmux {
+/*
+ otg {
+ nvidia,lanes = "otg-0", "otg-1", "otg-2";
+ nvidia,function = "xusb";
+ };
+*/
+ usb3 {
+ nvidia,lanes = "pcie-0";
+ nvidia,function = "usb3";
+
[RFC 2/8] mailbox: Add NVIDIA Tegra XUSB mailbox driver
From: Andrew Bresticker
The Tegra xHCI controller's firmware communicates requests to the host
processor through a mailbox interface. While there is only a single
physical channel, messages sent by the controller can be divided
into two groups: those intended for the PHY driver and those intended
for the host-controller driver. The requesting driver is assigned
one of two virtual channels when the single physical channel is
requested. All incoming messages are sent to both virtual channels.
Signed-off-by: Andrew Bresticker
Cc: Jassi Brar
Signed-off-by: Thierry Reding
---
drivers/mailbox/Kconfig | 8 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/tegra-xusb-mailbox.c | 290 +++
include/soc/tegra/xusb.h | 43 ++
4 files changed, 343 insertions(+)
create mode 100644 drivers/mailbox/tegra-xusb-mailbox.c
create mode 100644 include/soc/tegra/xusb.h
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index bbec500..6590165 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -71,4 +71,12 @@ config BCM2835_MBOX
the services of the Videocore. Say Y here if you want to use the
BCM2835 Mailbox.
+config TEGRA_XUSB_MBOX
+ tristate "NVIDIA Tegra XUSB Mailbox"
+ depends on MFD_TEGRA_XUSB
+ help
+ Mailbox driver for the XUSB complex found on NVIDIA Tegra124 and
+ later SoCs. The XUSB mailbox is used to communicate between the
+ XUSB microcontroller and the host processor.
+
endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 8e6d822..1dc9f9a 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -13,3 +13,5 @@ obj-$(CONFIG_PCC) += pcc.o
obj-$(CONFIG_ALTERA_MBOX) += mailbox-altera.o
obj-$(CONFIG_BCM2835_MBOX) += bcm2835-mailbox.o
+
+obj-$(CONFIG_TEGRA_XUSB_MBOX) += tegra-xusb-mailbox.o
diff --git a/drivers/mailbox/tegra-xusb-mailbox.c
b/drivers/mailbox/tegra-xusb-mailbox.c
new file mode 100644
index 000..4e2477d
--- /dev/null
+++ b/drivers/mailbox/tegra-xusb-mailbox.c
@@ -0,0 +1,290 @@
+/*
+ * NVIDIA Tegra XUSB mailbox driver
+ *
+ * Copyright (C) 2014 NVIDIA Corporation
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define XUSB_MBOX_NUM_CHANS2 /* Host + PHY */
+
+#define XUSB_CFG_ARU_MBOX_CMD 0xe4
+#define MBOX_DEST_FALCBIT(27)
+#define MBOX_DEST_PME BIT(28)
+#define MBOX_DEST_SMI BIT(29)
+#define MBOX_DEST_XHCIBIT(30)
+#define MBOX_INT_EN BIT(31)
+#define XUSB_CFG_ARU_MBOX_DATA_IN 0xe8
+#define CMD_DATA_SHIFT0
+#define CMD_DATA_MASK 0xff
+#define CMD_TYPE_SHIFT24
+#define CMD_TYPE_MASK 0xff
+#define XUSB_CFG_ARU_MBOX_DATA_OUT 0xec
+#define XUSB_CFG_ARU_MBOX_OWNER0xf0
+#define MBOX_OWNER_NONE 0
+#define MBOX_OWNER_FW 1
+#define MBOX_OWNER_SW 2
+#define XUSB_CFG_ARU_SMI_INTR 0x428
+#define MBOX_SMI_INTR_FW_HANG BIT(1)
+#define MBOX_SMI_INTR_EN BIT(3)
+
+struct tegra_xusb_mbox {
+ struct mbox_controller mbox;
+ struct regmap *fpci_regs;
+ spinlock_t lock;
+ int irq;
+};
+
+static inline u32 mbox_readl(struct tegra_xusb_mbox *mbox, unsigned long
offset)
+{
+ u32 val;
+
+ regmap_read(mbox->fpci_regs, offset, &val);
+
+ return val;
+}
+
+static inline void mbox_writel(struct tegra_xusb_mbox *mbox, u32 val,
+ unsigned long offset)
+{
+ regmap_write(mbox->fpci_regs, offset, val);
+}
+
+static inline struct tegra_xusb_mbox *to_tegra_mbox(struct mbox_controller *c)
+{
+ return container_of(c, struct tegra_xusb_mbox, mbox);
+}
+
+static inline u32 mbox_pack_msg(struct tegra_xusb_mbox_msg *msg)
+{
+ u32 val;
+
+ val = (msg->cmd & CMD_TYPE_MASK) << CMD_TYPE_SHIFT;
+ val |= (msg->data & CMD_DATA_MASK) << CMD_DATA_SHIFT;
+
+ return val;
+}
+
+static inline void mbox_unpack_msg(u32 val, struct tegra_xusb_mbox_msg *msg)
+{
+ msg->cmd = (val >> CMD_TYPE_SHIFT) & CMD_TYPE_MASK;
+ msg->data = (val >> CMD_DATA_SHIFT) & CMD_DATA_MASK;
+}
+
+static bool mbox_cmd_requires_ack(enum tegra_xusb_mbox_cmd cmd)
+{
+ switch (cmd) {
+ case MBOX_CMD_SET_BW:
+ case MBOX_CMD_ACK:
+ c
[RFC 4/8] pinctrl: tegra-xusb: Add USB PHY support
From: Andrew Bresticker In addition to the PCIe and SATA PHYs, the XUSB pad controller also supports 3 UTMI, 2 HSIC, and 2 USB3 PHYs. Each USB3 PHY uses a single PCIe or SATA lane and is mapped to one of the three UTMI ports. The xHCI controller will also send messages intended for the PHY driver, so request and listen for messages on the mailbox's PHY channel. Signed-off-by: Andrew Bresticker --- drivers/pinctrl/Kconfig |1 + drivers/pinctrl/pinctrl-tegra-xusb.c | 1270 +- 2 files changed, 1256 insertions(+), 15 deletions(-) diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig index 84dd2ed..0fc7b92 100644 --- a/drivers/pinctrl/Kconfig +++ b/drivers/pinctrl/Kconfig @@ -184,6 +184,7 @@ config PINCTRL_TEGRA210 config PINCTRL_TEGRA_XUSB def_bool y if ARCH_TEGRA + depends on MAILBOX select GENERIC_PHY select PINCONF select PINMUX diff --git a/drivers/pinctrl/pinctrl-tegra-xusb.c b/drivers/pinctrl/pinctrl-tegra-xusb.c index 2651d04..2578220 100644 --- a/drivers/pinctrl/pinctrl-tegra-xusb.c +++ b/drivers/pinctrl/pinctrl-tegra-xusb.c @@ -13,24 +13,60 @@ #include #include +#include #include #include #include #include #include #include +#include #include #include +#include + +#include +#include #include #include "core.h" #include "pinctrl-utils.h" +#define TEGRA_XUSB_UTMI_PHYS 3 +#define TEGRA_XUSB_USB3_PHYS 2 +#define TEGRA_XUSB_HSIC_PHYS 2 +#define TEGRA_XUSB_NUM_PHYS9 + +#define FUSE_SKU_CALIB_HS_CURR_LEVEL_PADX_SHIFT(x) ((x) ? 15 : 0) +#define FUSE_SKU_CALIB_HS_CURR_LEVEL_PAD_MASK 0x3f +#define FUSE_SKU_CALIB_HS_IREF_CAP_SHIFT 13 +#define FUSE_SKU_CALIB_HS_IREF_CAP_MASK 0x3 +#define FUSE_SKU_CALIB_HS_SQUELCH_LEVEL_SHIFT 11 +#define FUSE_SKU_CALIB_HS_SQUELCH_LEVEL_MASK 0x3 +#define FUSE_SKU_CALIB_HS_TERM_RANGE_ADJ_SHIFT 7 +#define FUSE_SKU_CALIB_HS_TERM_RANGE_ADJ_MASK 0xf + +#define XUSB_PADCTL_USB2_PORT_CAP 0x008 +#define XUSB_PADCTL_USB2_PORT_CAP_PORTX_CAP_SHIFT(x) ((x) * 4) +#define XUSB_PADCTL_USB2_PORT_CAP_PORT_CAP_MASK 0x3 +#define XUSB_PADCTL_USB2_PORT_CAP_DISABLED 0x0 +#define XUSB_PADCTL_USB2_PORT_CAP_HOST 0x1 +#define XUSB_PADCTL_USB2_PORT_CAP_DEVICE 0x2 +#define XUSB_PADCTL_USB2_PORT_CAP_OTG 0x3 + +#define XUSB_PADCTL_SS_PORT_MAP 0x014 +#define XUSB_PADCTL_SS_PORT_MAP_PORTX_SHIFT(x) ((x) * 4) +#define XUSB_PADCTL_SS_PORT_MAP_PORT_MASK 0x7 + #define XUSB_PADCTL_ELPG_PROGRAM 0x01c #define XUSB_PADCTL_ELPG_PROGRAM_AUX_MUX_LP0_VCORE_DOWN (1 << 26) #define XUSB_PADCTL_ELPG_PROGRAM_AUX_MUX_LP0_CLAMP_EN_EARLY (1 << 25) #define XUSB_PADCTL_ELPG_PROGRAM_AUX_MUX_LP0_CLAMP_EN (1 << 24) +#define XUSB_PADCTL_ELPG_PROGRAM_SSPX_ELPG_VCORE_DOWN(x) (1 << (18 + (x) * 4)) +#define XUSB_PADCTL_ELPG_PROGRAM_SSPX_ELPG_CLAMP_EN_EARLY(x) \ + (1 << (17 + (x) * 4)) +#define XUSB_PADCTL_ELPG_PROGRAM_SSPX_ELPG_CLAMP_EN(x) (1 << (16 + (x) * 4)) #define XUSB_PADCTL_IOPHY_PLL_P0_CTL1 0x040 #define XUSB_PADCTL_IOPHY_PLL_P0_CTL1_PLL0_LOCKDET (1 << 19) @@ -42,17 +78,136 @@ #define XUSB_PADCTL_IOPHY_PLL_P0_CTL2_TXCLKREF_EN (1 << 5) #define XUSB_PADCTL_IOPHY_PLL_P0_CTL2_TXCLKREF_SEL (1 << 4) +#define XUSB_PADCTL_IOPHY_USB3_PADX_CTL2(x) (0x058 + (x) * 4) +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_CDR_CNTL_SHIFT 24 +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_CDR_CNTL_MASK 0xff +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_EQ_Z_SHIFT 16 +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_EQ_Z_MASK 0x3f +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_EQ_G_SHIFT 8 +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_EQ_G_MASK 0x3f +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_EQ_SHIFT 8 +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_EQ_MASK 0x +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_WANDER_SHIFT 4 +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_WANDER_MASK 0x7 + +#define XUSB_PADCTL_IOPHY_USB3_PADX_CTL4(x) (0x068 + (x) * 4) +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL4_DFE_CNTL_TAP_SHIFT 24 +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL4_DFE_CNTL_TAP_MASK 0x1f +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL4_DFE_CNTL_AMP_SHIFT 16 +#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL4_DFE_CNTL_AMP_MASK 0x7f + +#define XUSB_PADCTL_IOPHY_MISC_PAD_PX_CTL2(x) ((x) < 2 ? 0x078 + (x) * 4 : \ + 0x0f8 + (x) * 4) +#define XUSB_PADCTL_IOPHY_MISC_PAD_CTL2_SPARE_IN_SHIFT 28 +#define XUSB_PADCTL_IOPHY_MISC_PAD_CTL2_SPARE_IN_MASK 0x3 + +#define XUSB_PADCTL_IOPHY_MISC_PAD_PX_CTL5(x) ((x) < 2 ? 0x090 + (x) * 4 : \ + 0x11c + (x) * 4) +#define XUSB_PADCTL_IOPHY_MISC_PAD_CTL5_RX_QEYE_EN (1 << 8) + +#define XUSB_PADCTL_IOPHY_MISC_PAD_PX_CTL6(x) ((x) < 2 ? 0x098 + (x) * 4 : \ + 0x128 + (x) * 4) +#define XUSB_PADCTL_IOPHY_MISC_PAD_CTL6_MISC_OUT_SHIFT 24 +#define XUSB_PADCTL_IOPHY_MISC_PAD_CTL6_MISC_OUT_G_Z_MASK 0x3f +#define XUSB_PADCTL_IOPHY_MISC_PAD_CTL6_MISC_OUT_TAP_MASK
[RFC 7/8] Start migrating XUSB away from MFD
From: Martyn Welch
This is my initial attempt to get xusb working without being a MFD on the
latest upstream kernel. It's still a bit hacky in places, but does seem to
get the USB2 up and working (USB3 device is recognised as a USB3 device
rather than enumberating as a USB2 device).
---
drivers/mailbox/tegra-xusb-mailbox.c | 16 ++---
drivers/mfd/tegra-xusb.c | 122 +++
drivers/usb/host/xhci-tegra.c| 52 +--
include/soc/tegra/xusb.h | 4 ++
4 files changed, 152 insertions(+), 42 deletions(-)
diff --git a/drivers/mailbox/tegra-xusb-mailbox.c
b/drivers/mailbox/tegra-xusb-mailbox.c
index 4e2477d..8924a6d 100644
--- a/drivers/mailbox/tegra-xusb-mailbox.c
+++ b/drivers/mailbox/tegra-xusb-mailbox.c
@@ -220,15 +220,11 @@ static struct mbox_chan *tegra_xusb_mbox_of_xlate(struct
mbox_controller *ctlr,
return chan;
}
-static const struct of_device_id tegra_xusb_mbox_of_match[] = {
- { .compatible = "nvidia,tegra124-xusb-mbox" },
- { },
-};
-MODULE_DEVICE_TABLE(of, tegra_xusb_mbox_of_match);
-
static int tegra_xusb_mbox_probe(struct platform_device *pdev)
{
struct tegra_xusb_mbox *mbox;
+ struct platform_device *parent;
+ struct tegra_xusb_shared_regs *sregs;
int ret;
mbox = devm_kzalloc(&pdev->dev, sizeof(*mbox), GFP_KERNEL);
@@ -236,7 +232,8 @@ static int tegra_xusb_mbox_probe(struct platform_device
*pdev)
return -ENOMEM;
platform_set_drvdata(pdev, mbox);
spin_lock_init(&mbox->lock);
- mbox->fpci_regs = dev_get_drvdata(pdev->dev.parent);
+ sregs = pdev->dev.platform_data;
+ mbox->fpci_regs = sregs->fpci_regs;
mbox->mbox.dev = &pdev->dev;
mbox->mbox.chans = devm_kcalloc(&pdev->dev, XUSB_MBOX_NUM_CHANS,
@@ -249,7 +246,9 @@ static int tegra_xusb_mbox_probe(struct platform_device
*pdev)
mbox->mbox.txpoll_period = 1;
mbox->mbox.of_xlate = tegra_xusb_mbox_of_xlate;
- mbox->irq = platform_get_irq(pdev, 0);
+ parent = to_platform_device(pdev->dev.parent);
+
+ mbox->irq = platform_get_irq(parent, 1);
if (mbox->irq < 0)
return mbox->irq;
ret = devm_request_irq(&pdev->dev, mbox->irq, tegra_xusb_mbox_irq, 0,
@@ -280,7 +279,6 @@ static struct platform_driver tegra_xusb_mbox_driver = {
.remove = tegra_xusb_mbox_remove,
.driver = {
.name = "tegra-xusb-mbox",
- .of_match_table = tegra_xusb_mbox_of_match,
},
};
module_platform_driver(tegra_xusb_mbox_driver);
diff --git a/drivers/mfd/tegra-xusb.c b/drivers/mfd/tegra-xusb.c
index e11fa23..e9cb365 100644
--- a/drivers/mfd/tegra-xusb.c
+++ b/drivers/mfd/tegra-xusb.c
@@ -18,6 +18,8 @@
#include
#include
+#include
+
static const struct of_device_id tegra_xusb_of_match[] = {
{ .compatible = "nvidia,tegra124-xusb", },
{},
@@ -30,39 +32,133 @@ static struct regmap_config tegra_fpci_regmap_config = {
.reg_stride = 4,
};
+struct tegra_xusb_priv {
+ struct platform_device *mbox_pdev;
+ struct platform_device *xhci_pdev;
+};
+
+static struct platform_device *tegra_xusb_add_device(struct device *parent,
+ const char *name, int id, const struct resource *res,
+ unsigned int num_res, const void *data, size_t size_data)
+{
+ int ret = -ENOMEM;
+ struct platform_device *pdev;
+
+ pdev = platform_device_alloc(name, id);
+ if (!pdev)
+ goto err_alloc;
+
+ pdev->dev.parent = parent;
+ pdev->dev.dma_mask = parent->dma_mask;
+ pdev->dev.dma_parms = parent->dma_parms;
+ pdev->dev.coherent_dma_mask = parent->coherent_dma_mask;
+ pdev->dev.of_node = parent->of_node;
+
+ ret = platform_device_add_resources(pdev,
+ res, num_res);
+ if (ret)
+ goto err;
+
+ ret = platform_device_add_data(pdev,
+ data, size_data);
+ if (ret)
+ goto err;
+
+ ret = platform_device_add(pdev);
+ if (ret)
+ goto err;
+
+ return pdev;
+
+err:
+ kfree(pdev->dev.dma_mask);
+
+err_alloc:
+ platform_device_put(pdev);
+ return ERR_PTR(ret);
+}
+
static int tegra_xusb_probe(struct platform_device *pdev)
{
struct resource *res;
- struct regmap *fpci_regs;
void __iomem *fpci_base;
int ret;
+ struct tegra_xusb_shared_regs *sregs;
+ struct tegra_xusb_priv *priv;
+
+ sregs = devm_kzalloc(&pdev->dev, sizeof(*sregs), GFP_KERNEL);
+ if (!sregs)
+ return -ENOMEM;
+
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
- res = platform_get_re
[RFC 5/8] pinctrl: tegra-xusb: Support PHY subnodes
From: Thierry Reding
Signed-off-by: Thierry Reding
---
drivers/pinctrl/pinctrl-tegra-xusb.c | 492 ---
include/soc/tegra/xusb.h | 7 +
2 files changed, 296 insertions(+), 203 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-tegra-xusb.c
b/drivers/pinctrl/pinctrl-tegra-xusb.c
index 2578220..f359b42 100644
--- a/drivers/pinctrl/pinctrl-tegra-xusb.c
+++ b/drivers/pinctrl/pinctrl-tegra-xusb.c
@@ -33,11 +33,6 @@
#include "core.h"
#include "pinctrl-utils.h"
-#define TEGRA_XUSB_UTMI_PHYS 3
-#define TEGRA_XUSB_USB3_PHYS 2
-#define TEGRA_XUSB_HSIC_PHYS 2
-#define TEGRA_XUSB_NUM_PHYS9
-
#define FUSE_SKU_CALIB_HS_CURR_LEVEL_PADX_SHIFT(x) ((x) ? 15 : 0)
#define FUSE_SKU_CALIB_HS_CURR_LEVEL_PAD_MASK 0x3f
#define FUSE_SKU_CALIB_HS_IREF_CAP_SHIFT 13
@@ -254,13 +249,25 @@ struct tegra_xusb_fuse_calibration {
u32 hs_squelch_level;
};
-struct tegra_xusb_usb3_port {
- unsigned int lane;
+struct tegra_xusb_usb3_phy {
+ struct tegra_xusb_padctl *padctl;
bool context_saved;
- u32 tap1_val;
- u32 amp_val;
- u32 ctle_z_val;
- u32 ctle_g_val;
+ unsigned int index;
+ unsigned int lane;
+ unsigned int port;
+
+ u32 tap1;
+ u32 amp;
+ u32 ctle_z;
+ u32 ctle_g;
+};
+
+struct tegra_xusb_utmi_phy {
+ struct tegra_xusb_padctl *padctl;
+ unsigned int index;
+
+ unsigned int hs_curr_level_offset;
+ struct regulator *supply;
};
struct tegra_xusb_padctl {
@@ -284,10 +291,7 @@ struct tegra_xusb_padctl {
struct mbox_client mbox_client;
struct mbox_chan *mbox_chan;
- struct tegra_xusb_usb3_port usb3_ports[TEGRA_XUSB_USB3_PHYS];
unsigned int utmi_enable;
- unsigned int hs_curr_level_offset[TEGRA_XUSB_UTMI_PHYS];
- struct regulator *vbus[TEGRA_XUSB_UTMI_PHYS];
struct regulator *vddio_hsic;
};
@@ -337,19 +341,6 @@ static inline bool lane_is_pcie_or_sata(unsigned int lane)
return lane >= PIN_PCIE_0 && lane <= PIN_SATA_0;
}
-static int lane_to_usb3_port(struct tegra_xusb_padctl *padctl,
-unsigned int lane)
-{
- unsigned int i;
-
- for (i = 0; i < TEGRA_XUSB_USB3_PHYS; i++) {
- if (padctl->usb3_ports[i].lane == lane)
- return i;
- }
-
- return -EINVAL;
-}
-
static int tegra_xusb_padctl_get_groups_count(struct pinctrl_dev *pinctrl)
{
struct tegra_xusb_padctl *padctl = pinctrl_dev_get_drvdata(pinctrl);
@@ -382,8 +373,6 @@ static int tegra_xusb_padctl_get_group_pins(struct
pinctrl_dev *pinctrl,
enum tegra_xusb_padctl_param {
TEGRA_XUSB_PADCTL_IDDQ,
- TEGRA_XUSB_PADCTL_USB3_PORT,
- TEGRA_XUSB_PADCTL_USB2_PORT,
TEGRA_XUSB_PADCTL_HSIC_STROBE_TRIM,
TEGRA_XUSB_PADCTL_HSIC_RX_STROBE_TRIM,
TEGRA_XUSB_PADCTL_HSIC_RX_DATA_TRIM,
@@ -400,8 +389,6 @@ static const struct tegra_xusb_padctl_property {
enum tegra_xusb_padctl_param param;
} properties[] = {
{ "nvidia,iddq", TEGRA_XUSB_PADCTL_IDDQ },
- { "nvidia,usb3-port", TEGRA_XUSB_PADCTL_USB3_PORT },
- { "nvidia,usb2-port", TEGRA_XUSB_PADCTL_USB2_PORT },
{ "nvidia,hsic-strobe-trim", TEGRA_XUSB_PADCTL_HSIC_STROBE_TRIM },
{ "nvidia,hsic-rx-strobe-trim", TEGRA_XUSB_PADCTL_HSIC_RX_STROBE_TRIM },
{ "nvidia,hsic-rx-data-trim", TEGRA_XUSB_PADCTL_HSIC_RX_DATA_TRIM },
@@ -620,28 +607,6 @@ static int tegra_xusb_padctl_pinconf_group_get(struct
pinctrl_dev *pinctrl,
value = 1;
break;
- case TEGRA_XUSB_PADCTL_USB3_PORT:
- value = lane_to_usb3_port(padctl, group);
- if (value < 0) {
- dev_err(padctl->dev,
- "Pin %d not mapped to USB3 port\n", group);
- return -EINVAL;
- }
- break;
-
- case TEGRA_XUSB_PADCTL_USB2_PORT:
- port = lane_to_usb3_port(padctl, group);
- if (port < 0) {
- dev_err(padctl->dev,
- "Pin %d not mapped to USB3 port\n", group);
- return -EINVAL;
- }
-
- value = padctl_readl(padctl, XUSB_PADCTL_SS_PORT_MAP) >>
- XUSB_PADCTL_SS_PORT_MAP_PORTX_SHIFT(port);
- value &= XUSB_PADCTL_SS_PORT_MAP_PORT_MASK;
- break;
-
case TEGRA_XUSB_PADCTL_HSIC_STROBE_TRIM:
if (!lane_is_hsic(group)) {
dev_err(padctl->dev, "Pin %d not an HSIC\n", group);
@@ -744,10 +709,15 @@ static int tegra_xusb_padctl_pinconf_group_get(struct
pinctrl_dev *pinctrl,
dev_err(padctl->dev, "Pin %d is not an OTG pad\n",
group);
return -EINVAL;
- }
+ } else {
+ unsigned int
[RFC 3/8] usb: xhci: Add NVIDIA Tegra xHCI host-controller driver
From: Andrew Bresticker Add support for the on-chip xHCI host controller present on Tegra SoCs. The controller requires external firmware which must be loaded before using the controller. This driver loads the firmware, starts the controller, and is able to service host-specific messages sent by the controller's firmware. The controller also supports USB device mode as well as powergating of the SuperSpeed and host-controller logic when not in use, but support for these is not yet implemented. Based on work by: Ajay Gupta Bharath Yadav Signed-off-by: Andrew Bresticker Cc: Mathias Nyman Cc: Greg Kroah-Hartman Signed-off-by: Thierry Reding --- drivers/usb/host/Kconfig | 10 + drivers/usb/host/Makefile | 1 + drivers/usb/host/xhci-tegra.c | 947 ++ 3 files changed, 958 insertions(+) create mode 100644 drivers/usb/host/xhci-tegra.c diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 079991e..ae75498 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -57,6 +57,16 @@ config USB_XHCI_RCAR Say 'Y' to enable the support for the xHCI host controller found in Renesas R-Car ARM SoCs. +config USB_XHCI_TEGRA + tristate "xHCI support for NVIDIA Tegra SoCs" + depends on MFD_TEGRA_XUSB || COMPILE_TEST + depends on MAILBOX + depends on RESET_CONTROLLER + select FW_LOADER + ---help--- + Say 'Y' to enable the support for the xHCI host controller + found in NVIDIA Tegra124 and later SoCs. + endif # USB_XHCI_HCD config USB_EHCI_HCD diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index 754efaa..d15a411 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -30,6 +30,7 @@ endif obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o +obj-$(CONFIG_USB_XHCI_TEGRA) += xhci-tegra.o obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c new file mode 100644 index 000..d510dc5 --- /dev/null +++ b/drivers/usb/host/xhci-tegra.c @@ -0,0 +1,947 @@ +/* + * NVIDIA Tegra xHCI host controller driver + * + * Copyright (C) 2014 NVIDIA Corporation + * Copyright (C) 2014 Google, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "xhci.h" + +#define TEGRA_XHCI_SS_CLK_HIGH_SPEED 12000 +#define TEGRA_XHCI_SS_CLK_LOW_SPEED 1200 + +/* FPCI CFG registers */ +#define XUSB_CFG_1 0x004 +#define XUSB_IO_SPACE_EN BIT(0) +#define XUSB_MEM_SPACE_EN BIT(1) +#define XUSB_BUS_MASTER_ENBIT(2) +#define XUSB_CFG_4 0x010 +#define XUSB_BASE_ADDR_SHIFT 15 +#define XUSB_BASE_ADDR_MASK 0x1 +#define XUSB_CFG_ARU_C11_CSBRANGE 0x41c +#define XUSB_CFG_CSB_BASE_ADDR 0x800 + +/* IPFS registers */ +#define IPFS_XUSB_HOST_CONFIGURATION_0 0x180 +#define IPFS_EN_FPCI BIT(0) +#define IPFS_XUSB_HOST_INTR_MASK_0 0x188 +#define IPFS_IP_INT_MASK BIT(16) +#define IPFS_XUSB_HOST_CLKGATE_HYSTERESIS_00x1bc + +#define CSB_PAGE_SELECT_MASK 0x7f +#define CSB_PAGE_SELECT_SHIFT 9 +#define CSB_PAGE_OFFSET_MASK 0x1ff +#define CSB_PAGE_SELECT(addr) ((addr) >> (CSB_PAGE_SELECT_SHIFT) &\ +CSB_PAGE_SELECT_MASK) +#define CSB_PAGE_OFFSET(addr) ((addr) & CSB_PAGE_OFFSET_MASK) + +/* Falcon CSB registers */ +#define XUSB_FALC_CPUCTL 0x100 +#define CPUCTL_STARTCPU BIT(1) +#define CPUCTL_STATE_HALTED BIT(4) +#define CPUCTL_STATE_STOPPED BIT(5) +#define XUSB_FALC_BOOTVEC 0x104 +#define XUSB_FALC_DMACTL 0x10c +#define XUSB_FALC_IMFILLRNG1 0x154 +#define IMFILLRNG1_TAG_MASK 0x +#define IMFILLRNG1_TAG_LO_SHIFT 0 +#define IMFILLRNG1_TAG_HI_SHIFT 16 +#define XUSB_FALC_IMFILLCTL0x158 + +/* MP CSB registers */ +#define XUSB_CSB_MP_ILOAD_ATTR 0x101a00 +#define XUSB_CSB_MP_ILOAD_BASE_LO 0x101a04 +#define XUSB_CSB_MP_ILOAD_BASE_HI 0x101a08 +#define XUSB_CSB_MP_L2IMEMOP_SIZE 0x101a10 +#define L2IMEMOP_SIZE_SRC_OFFSET_SHIFT
[RFC 8/8] Registering mailbox from XUSB Child - Work in progress
From: Martyn Welch
The mailbox API expects the device node to have a of_node associated with
it. Because the child doesn't have it's own node, in the previous patch
tegra_xusb_add_device() was assigning the parents of_node to it's children.
Unfortunately this results in the parents probe being called when the
device is added.
To try and get around this, in this patch we use the parent device node
(which legitimately has an of_node assigned to it). Unfortuntely this
results in the parents device node being stored in the mbox_client
structure, which is used in the receive callback (tegra_xhci_mbox_rx) to
get the required driver data, so a bit of fiddling is needed to get the
child's data rather then the parents.
This loads an appears to be doing the right thing, up until a USB3 device
is plugged into the port and it gets enumerated as USB2 :-(
---
drivers/mailbox/tegra-xusb-mailbox.c | 2 +-
drivers/mfd/tegra-xusb.c | 6 --
drivers/usb/host/xhci-tegra.c| 6 +++---
include/soc/tegra/xusb.h | 5 +
4 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/mailbox/tegra-xusb-mailbox.c
b/drivers/mailbox/tegra-xusb-mailbox.c
index 8924a6d..1421712 100644
--- a/drivers/mailbox/tegra-xusb-mailbox.c
+++ b/drivers/mailbox/tegra-xusb-mailbox.c
@@ -235,7 +235,7 @@ static int tegra_xusb_mbox_probe(struct platform_device
*pdev)
sregs = pdev->dev.platform_data;
mbox->fpci_regs = sregs->fpci_regs;
- mbox->mbox.dev = &pdev->dev;
+ mbox->mbox.dev = pdev->dev.parent;
mbox->mbox.chans = devm_kcalloc(&pdev->dev, XUSB_MBOX_NUM_CHANS,
sizeof(*mbox->mbox.chans), GFP_KERNEL);
if (!mbox->mbox.chans)
diff --git a/drivers/mfd/tegra-xusb.c b/drivers/mfd/tegra-xusb.c
index e9cb365..d615a94 100644
--- a/drivers/mfd/tegra-xusb.c
+++ b/drivers/mfd/tegra-xusb.c
@@ -32,11 +32,6 @@ static struct regmap_config tegra_fpci_regmap_config = {
.reg_stride = 4,
};
-struct tegra_xusb_priv {
- struct platform_device *mbox_pdev;
- struct platform_device *xhci_pdev;
-};
-
static struct platform_device *tegra_xusb_add_device(struct device *parent,
const char *name, int id, const struct resource *res,
unsigned int num_res, const void *data, size_t size_data)
diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
index 0172fe2..e49dbda 100644
--- a/drivers/usb/host/xhci-tegra.c
+++ b/drivers/usb/host/xhci-tegra.c
@@ -552,7 +552,8 @@ static void tegra_xhci_mbox_work(struct work_struct *work)
static void tegra_xhci_mbox_rx(struct mbox_client *cl, void *data)
{
- struct tegra_xhci_hcd *tegra = dev_get_drvdata(cl->dev);
+ struct tegra_xusb_priv *priv = dev_get_drvdata(cl->dev);
+ struct tegra_xhci_hcd *tegra = dev_get_drvdata(&priv->xhci_pdev->dev);
struct tegra_xusb_mbox_msg *msg = data;
if (is_host_mbox_message(msg->cmd)) {
@@ -694,7 +695,6 @@ static int tegra_xhci_probe(struct platform_device *pdev)
return -ENOMEM;
tegra->dev = &pdev->dev;
platform_set_drvdata(pdev, tegra);
-
match = of_match_device(tegra_xhci_of_match, pdev->dev.parent);
if(!match)
return -ENODEV;
@@ -811,7 +811,7 @@ static int tegra_xhci_probe(struct platform_device *pdev)
goto disable_clk;
INIT_WORK(&tegra->mbox_req_work, tegra_xhci_mbox_work);
- tegra->mbox_client.dev = &pdev->dev;
+ tegra->mbox_client.dev = pdev->dev.parent;
tegra->mbox_client.tx_block = true;
tegra->mbox_client.tx_tout = 0;
tegra->mbox_client.rx_callback = tegra_xhci_mbox_rx;
diff --git a/include/soc/tegra/xusb.h b/include/soc/tegra/xusb.h
index d3c4dbd..f580b1d 100644
--- a/include/soc/tegra/xusb.h
+++ b/include/soc/tegra/xusb.h
@@ -47,6 +47,11 @@ struct tegra_xusb_mbox_msg {
u32 data;
};
+struct tegra_xusb_priv {
+ struct platform_device *mbox_pdev;
+ struct platform_device *xhci_pdev;
+};
+
struct tegra_xusb_shared_regs {
struct regmap *fpci_regs;
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 1/8] mfd: Add driver for NVIDIA Tegra XUSB
From: Andrew Bresticker
Add an MFD driver for the XUSB host complex found on NVIDIA Tegra124
and later SoCs.
Signed-off-by: Andrew Bresticker
Cc: Samuel Ortiz
Cc: Lee Jones
Signed-off-by: Thierry Reding
---
drivers/mfd/Kconfig | 7 +
drivers/mfd/Makefile | 1 +
drivers/mfd/tegra-xusb.c | 75
3 files changed, 83 insertions(+)
create mode 100644 drivers/mfd/tegra-xusb.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 99d6367..f8f9ea3 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1479,6 +1479,13 @@ config MFD_STW481X
in various ST Microelectronics and ST-Ericsson embedded
Nomadik series.
+config MFD_TEGRA_XUSB
+ tristate "NVIDIA Tegra XUSB"
+ depends on ARCH_TEGRA
+ select MFD_CORE
+ help
+ Support for the XUSB complex found on NVIDIA Tegra124 and later SoCs.
+
menu "Multimedia Capabilities Port drivers"
depends on ARCH_SA1100
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index a59e3fc..8646703 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -188,6 +188,7 @@ obj-$(CONFIG_MFD_HI6421_PMIC) += hi6421-pmic-core.o
obj-$(CONFIG_MFD_DLN2) += dln2.o
obj-$(CONFIG_MFD_RT5033) += rt5033.o
obj-$(CONFIG_MFD_SKY81452) += sky81452.o
+obj-$(CONFIG_MFD_TEGRA_XUSB) += tegra-xusb.o
intel-soc-pmic-objs:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
diff --git a/drivers/mfd/tegra-xusb.c b/drivers/mfd/tegra-xusb.c
new file mode 100644
index 000..e11fa23
--- /dev/null
+++ b/drivers/mfd/tegra-xusb.c
@@ -0,0 +1,75 @@
+/*
+ * NVIDIA Tegra XUSB MFD driver
+ *
+ * Copyright (C) 2015 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static const struct of_device_id tegra_xusb_of_match[] = {
+ { .compatible = "nvidia,tegra124-xusb", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, tegra_xusb_of_match);
+
+static struct regmap_config tegra_fpci_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+};
+
+static int tegra_xusb_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+ struct regmap *fpci_regs;
+ void __iomem *fpci_base;
+ int ret;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ fpci_base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(fpci_base))
+ return PTR_ERR(fpci_base);
+
+ tegra_fpci_regmap_config.max_register = res->end - res->start - 3;
+ fpci_regs = devm_regmap_init_mmio(&pdev->dev, fpci_base,
+ &tegra_fpci_regmap_config);
+ if (IS_ERR(fpci_regs)) {
+ ret = PTR_ERR(fpci_regs);
+ dev_err(&pdev->dev, "Failed to init regmap: %d\n", ret);
+ return ret;
+ }
+ platform_set_drvdata(pdev, fpci_regs);
+
+ ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to add sub-devices: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static struct platform_driver tegra_xusb_driver = {
+ .probe = tegra_xusb_probe,
+ .driver = {
+ .name = "tegra-xusb",
+ .of_match_table = tegra_xusb_of_match,
+ },
+};
+module_platform_driver(tegra_xusb_driver);
+
+MODULE_DESCRIPTION("NVIDIA Tegra XUSB MFD");
+MODULE_AUTHOR("Andrew Bresticker ");
+MODULE_LICENSE("GPL v2");
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 7/8] Start migrating XUSB away from MFD
On 02/11/15 12:47, Lee Jones wrote: On Mon, 02 Nov 2015, Martyn Welch wrote: From: Martyn Welch This is my initial attempt to get xusb working without being a MFD on the latest upstream kernel. It's still a bit hacky in places, but does seem to get the USB2 up and working (USB3 device is recognised as a USB3 device rather than enumberating as a USB2 device). After my 20 second look at the 2 patches of this set you sent me, I've concluded that it looks barking mad. In patch 2 you're adding the XUSB MFD driver, then in this patch you're telling us that you're moving away from MFD despite adding more code to the subsystem. Hi Lee, Sorry, seems git send-email added you of it's own volition. I've sent these patches to the mailing list for comment/help not for submission. As mentioned in the cover email, the first 5 patches are from an existing series that has been rejected. The later 3 patches show my modifications. I have not yet moved these files from the MFD directory, but will before submission (the series will be reworked so that the driver never goes into the MFD area). Besides, I'm never applying a patch that self confesses to be "hacky in places" into Mainline, ever. As I mentioned before, I'm posting these patches for comment (hence why I've marked them as "RFC" not "PATCH"). Martyn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 7/8] Start migrating XUSB away from MFD
On 02/11/15 13:27, Lee Jones wrote: On Mon, 02 Nov 2015, Martyn Welch wrote: On 02/11/15 12:47, Lee Jones wrote: On Mon, 02 Nov 2015, Martyn Welch wrote: Besides, I'm never applying a patch that self confesses to be "hacky in places" into Mainline, ever. As I mentioned before, I'm posting these patches for comment (hence why I've marked them as "RFC" not "PATCH"). I did notice that this was an RFC -- and this was my Comment. ;) Which I'm prepared to completely accept and wouldn't have it any other way :-) Martyn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/8] Add support for NVIDIA Tegra XUSB
On 02/11/15 17:27, Andrew Bresticker wrote: Hi Martyn, On Mon, Nov 2, 2015 at 3:55 AM, Martyn Welch wrote: This series is based on commits that can be found in the git tree here: https://github.com/thierryreding/linux/commits/staging/xhci I have included the patches I've used from that tree as patches 1-5. The above patches were submitted for review back in May: https://lkml.org/lkml/2015/5/4/574 The approach taken in these patches was deemed not appropriate (treating the XUSB as a MFD). In patch 6 I add the bindings based in those submitted for review here (with a few modifications currently required by the driver): https://www.spinics.net/lists/linux-usb/msg130940.html I have included my changes to the original patch series in patch 7. With these modifications the patch series builds and works, but is rather hacky. Devices for the mailbox driver and xHCI driver are now created in the xusb driver (still under the mfd directory for now - it will be moved before this series is submitted properly). As the child devices use infrastructure which expects the device to be associated with a of_node, it has been necessary to point the child device at the parents of_node where this is needed. This approach did not seem viable for the mailbox API, so to get that working the child device node was pointed to the parents of_node (in tegra_xusb_add_device). The unfortunate side effect of this is that upon device creation the parents probe routine gets called... Not good. Patch 8 attempts to resolve this. When passing the parents device node to the mailbox API, the mailbox's receive callback was raising errors as that function is looking for the drvdata stored in the child's device node, but getting the parents. This patch jumps though a few hoops to get to the child's device node. After my last submission, we had a discussion about the mailbox and decided not to use the mailbox framework and instead use a private API between the xHCI driver and the XUSB_PADCTL driver. Ok. Unfortunately, whilst the receive callback seems to be getting the right drvdata, USB3 devices are being enumerated as USB2 devices rather than USB3 devices, so something is clearly not right. Tegra124? Tegra210? Which board? Tegra124, nyan-blaze. Martyn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vme: tsi148: silence uninitialized variable warning
On 5 October 2015 at 04:59, Dmitry Kalinkin wrote:
> The warning is a false positive.
>
That seems very likely.
Please could you role this into the original patch (vme: change bus
error handling scheme)?
Martyn
> drivers/vme/bridges/vme_tsi148.c: In function 'tsi148_master_write':
> drivers/vme/bridges/vme_tsi148.c:1358:31: warning: 'handler' may be used
> uninitialized in this function [-Wmaybe-uninitialized]
>vme_unregister_error_handler(handler);
>^
> drivers/vme/bridges/vme_tsi148.c: In function 'tsi148_master_read':
> drivers/vme/bridges/vme_tsi148.c:1260:31: warning: 'handler' may be used
> uninitialized in this function [-Wmaybe-uninitialized]
>vme_unregister_error_handler(handler);
>^
>
> Fixes: 0b0496625715 ("vme: change bus error handling scheme")
> Signed-off-by: Dmitry Kalinkin
> ---
> drivers/vme/bridges/vme_tsi148.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vme/bridges/vme_tsi148.c
> b/drivers/vme/bridges/vme_tsi148.c
> index d1e383b..6052483 100644
> --- a/drivers/vme/bridges/vme_tsi148.c
> +++ b/drivers/vme/bridges/vme_tsi148.c
> @@ -1186,7 +1186,7 @@ static ssize_t tsi148_master_read(struct
> vme_master_resource *image, void *buf,
> int retval, enabled;
> unsigned long long vme_base, size;
> u32 aspace, cycle, dwidth;
> - struct vme_error_handler *handler;
> + struct vme_error_handler *handler = NULL;
> struct vme_bridge *tsi148_bridge;
> void __iomem *addr = image->kern_base + offset;
> unsigned int done = 0;
> @@ -1276,7 +1276,7 @@ static ssize_t tsi148_master_write(struct
> vme_master_resource *image, void *buf,
> unsigned int done = 0;
> unsigned int count32;
>
> - struct vme_error_handler *handler;
> + struct vme_error_handler *handler = NULL;
> struct vme_bridge *tsi148_bridge;
> struct tsi148_driver *bridge;
>
> --
> 1.8.3.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: dts: am335x: Add support for Bosch Guardian
The Bosch Guardian is a TI am335x based device.
It's hardware specifications are as follows:
* 256 MB DDR3 memory
* 512 MB NAND Flash
* USB OTG
* RS232
* MicroSD external storage
* LCD Display interface
Signed-off-by: Martyn Welch
---
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/am335x-guardian.dts | 511 ++
2 files changed, 512 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-guardian.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index bd40148a15b2..1ad9a6307b0a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -719,6 +719,7 @@ dtb-$(CONFIG_SOC_AM33XX) += \
am335x-cm-t335.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
+ am335x-guardian.dtb \
am335x-icev2.dtb \
am335x-lxm.dtb \
am335x-moxa-uc-2101.dtb \
diff --git a/arch/arm/boot/dts/am335x-guardian.dts
b/arch/arm/boot/dts/am335x-guardian.dts
new file mode 100644
index ..d8652ab014b2
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-guardian.dts
@@ -0,0 +1,511 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2018 Robert Bosch Power Tools GmbH
+ */
+/dts-v1/;
+
+#include "am33xx.dtsi"
+#include
+#include
+
+/ {
+ model = "Bosch AM335x Guardian";
+ compatible = "bosch,am335x-guardian", "ti,am33xx";
+
+ chosen {
+ stdout-path = &uart0;
+ tick-timer = &timer2;
+ };
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = <&dcdc2_reg>;
+ };
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ reg = <0x8000 0x1000>; /* 256 MB */
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio_keys_pins>;
+
+ button21 {
+ label = "guardian-power-button";
+ linux,code = ;
+ gpios = <&gpio2 21 0>;
+ wakeup-source;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&leds_pins>;
+
+ led1 {
+ label = "green:heartbeat";
+ gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ default-state = "off";
+ };
+
+ led2 {
+ label = "green:mmc0";
+ gpios = <&gpio1 26 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "mmc0";
+ default-state = "off";
+ };
+ };
+
+ panel {
+ compatible = "ti,tilcdc,panel";
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&lcd_pins_default &lcd_disen_pins>;
+ pinctrl-1 = <&lcd_pins_sleep>;
+
+ display-timings {
+ 320x240 {
+ hactive = <320>;
+ vactive = <240>;
+ hback-porch = <68>;
+ hfront-porch= <20>;
+ hsync-len = <1>;
+ vback-porch = <18>;
+ vfront-porch= <4>;
+ vsync-len = <1>;
+ clock-frequency = <900>;
+ hsync-active= <0>;
+ vsync-active= <0>;
+ };
+ };
+ panel-info {
+ ac-bias = <255>;
+ ac-bias-intrpt= <0>;
+ dma-burst-sz = <16>;
+ bpp = <24>;
+ bus-width = <16>;
+ fdd = <0x80>;
+ sync-edge = <0>;
+ sync-ctrl = <1>;
+ raster-order = <0>;
+ fifo-th = <0>;
+ };
+
+ };
+
+ pwm7: dmtimer-pwm {
+ compatible = "ti,omap-dmtimer-pwm&qu
[PATCH v3 1/2] dt-bindings: Add binding document for NOA1305
Document the ON Semiconductor NOA1305 ambient light sensor devicetree
bindings.
Signed-off-by: Martyn Welch
Reviewed-by: Rob Herring
---
Changes:
v2: Same as v1.
v3: Same as v2.
.../bindings/iio/light/noa1305.yaml | 44 +++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/light/noa1305.yaml
diff --git a/Documentation/devicetree/bindings/iio/light/noa1305.yaml
b/Documentation/devicetree/bindings/iio/light/noa1305.yaml
new file mode 100644
index ..17e7f140b69b
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/noa1305.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/noa1305.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ON Semiconductor NOA1305 Ambient Light Sensor
+
+maintainers:
+ - Martyn Welch
+
+description: |
+ Ambient sensing with an i2c interface.
+
+ https://www.onsemi.com/pub/Collateral/NOA1305-D.PDF
+
+properties:
+ compatible:
+enum:
+ - onnn,noa1305
+
+ reg:
+maxItems: 1
+
+ vin-supply:
+description: Regulator that provides power to the sensor
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+i2c {
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+light@39 {
+compatible = "onnn,noa1305";
+reg = <0x39>;
+};
+};
+...
--
2.20.1
[PATCH v3 2/2] iio: light: noa1305: Add support for NOA1305
This driver adds the initial support for the ON Semiconductor
NOA1305 Ambient Light Sensor.
Originally written by Sergei Miroshnichenko. Found here:
https://github.com/EmcraftSystems/linux-upstream/commit/196d6cf897e632d2cb82d45484bd7a1bfdd5b6d9
Signed-off-by: Sergei M
Signed-off-by: Martyn Welch
---
Changes:
v2:
- Correcting authorship and SOB.
v3:
- Improve register define naming.
- Follow IIO convention of interleaving register bit definitions with
register defintions.
- Use proper endian swapping.
- Process raw sensor count into Lux.
- Avoid setting variables to zero when not needed.
- Check return value of i2c writes.
- Implement disabling of regulator as a devm action.
- Remove excessive white spacing.
drivers/iio/light/Kconfig | 10 ++
drivers/iio/light/Makefile | 1 +
drivers/iio/light/noa1305.c | 278
3 files changed, 289 insertions(+)
create mode 100644 drivers/iio/light/noa1305.c
diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index 954c958cfc43..d1db0ec0d0f5 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -309,6 +309,16 @@ config MAX44009
To compile this driver as a module, choose M here:
the module will be called max44009.
+config NOA1305
+ tristate "ON Semiconductor NOA1305 ambient light sensor"
+ depends on I2C
+ help
+Say Y here if you want to build support for the ON Semiconductor
+NOA1305 ambient light sensor.
+
+To compile this driver as a module, choose M here:
+The module will be called noa1305.
+
config OPT3001
tristate "Texas Instruments OPT3001 Light Sensor"
depends on I2C
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index e40794fbb435..00d1f9b98f39 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_LTR501) += ltr501.o
obj-$(CONFIG_LV0104CS) += lv0104cs.o
obj-$(CONFIG_MAX44000) += max44000.o
obj-$(CONFIG_MAX44009) += max44009.o
+obj-$(CONFIG_NOA1305) += noa1305.o
obj-$(CONFIG_OPT3001) += opt3001.o
obj-$(CONFIG_PA12203001) += pa12203001.o
obj-$(CONFIG_RPR0521) += rpr0521.o
diff --git a/drivers/iio/light/noa1305.c b/drivers/iio/light/noa1305.c
new file mode 100644
index ..02b0cf48c2be
--- /dev/null
+++ b/drivers/iio/light/noa1305.c
@@ -0,0 +1,278 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Support for ON Semiconductor NOA1305 ambient light sensor
+ *
+ * Copyright (C) 2016 Emcraft Systems
+ * Copyright (C) 2019 Collabora Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define NOA1305_REG_POWER_CONTROL 0x0
+#define NOA1305_POWER_CONTROL_DOWN 0x00
+#define NOA1305_POWER_CONTROL_ON 0x08
+#define NOA1305_REG_RESET 0x1
+#define NOA1305_RESET_RESET 0x10
+#define NOA1305_REG_INTEGRATION_TIME 0x2
+#define NOA1305_INTEGR_TIME_800MS0x00
+#define NOA1305_INTEGR_TIME_400MS0x01
+#define NOA1305_INTEGR_TIME_200MS0x02
+#define NOA1305_INTEGR_TIME_100MS0x03
+#define NOA1305_INTEGR_TIME_50MS 0x04
+#define NOA1305_INTEGR_TIME_25MS 0x05
+#define NOA1305_INTEGR_TIME_12_5MS 0x06
+#define NOA1305_INTEGR_TIME_6_25MS 0x07
+#define NOA1305_REG_INT_SELECT 0x3
+#define NOA1305_INT_SEL_ACTIVE_HIGH 0x01
+#define NOA1305_INT_SEL_ACTIVE_LOW 0x02
+#define NOA1305_INT_SEL_INACTIVE 0x03
+#define NOA1305_REG_INT_THRESH_LSB 0x4
+#define NOA1305_REG_INT_THRESH_MSB 0x5
+#define NOA1305_REG_ALS_DATA_LSB 0x6
+#define NOA1305_REG_ALS_DATA_MSB 0x7
+#define NOA1305_REG_DEVICE_ID_LSB 0x8
+#define NOA1305_REG_DEVICE_ID_MSB 0x9
+
+#define NOA1305_DEVICE_ID 0x0519
+#define NOA1305_DRIVER_NAME"noa1305"
+
+struct noa1305_priv {
+ struct i2c_client *client;
+ struct regmap *regmap;
+ struct regulator *vin_reg;
+};
+
+static int noa1305_measure(struct noa1305_priv *priv)
+{
+ __le16 data;
+ int count;
+ int ret;
+
+ ret = regmap_bulk_read(priv->regmap, NOA1305_REG_ALS_DATA_LSB, &data,
+ 2);
+ if (ret < 0)
+ return ret;
+
+ /*
+* Lux = count / ( * )
+*
+* Integration Constant = 7.7
+* Integration Time in Seconds (currently) = 800ms
+*/
+ return (le16_to_cpu(data) * 100) / (77 * 8);
+}
+
+static const struct iio_chan_spec noa1305_channels[] = {
+ {
+ .type = IIO_LIGHT,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
+ }
+};
+
+static int noa1305_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long mask)
+{
+ int ret = -EINVAL;
+ struct
[PATCH v2 1/2] dt-bindings: Add vendor prefix for Catalyst Semiconductor
Add vendor prefix "catalyst" for Catalyst Semiconductor which is already in use but undocumented. Signed-off-by: Martyn Welch Reviewed-by: Rob Herring --- Changes in v2: None 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 389508584f48..d80b23b7771f 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -65,6 +65,7 @@ bticino Bticino International calxedaCalxeda capellaCapella Microsystems, Inc cascodaCascoda, Ltd. +catalyst Catalyst Semiconductor, Inc cavium Cavium, Inc. cdns Cadence Design Systems Inc. cdtech CDTech(H.K.) Electronics Limited -- 2.20.1
[PATCH v2 2/2] ARM: dts: imx6: Add support for Phytec phyBOARD i.MX6UL Segin
The Phytec phyBOARD Segin is i.MX6 based SBC, available with either an
i.MX6UL or i.MX6ULL SOM and various add-on boards.
The following adds support for the "Full Featured" version of the Segin,
which is provided with the i.MX6UL SOM and the PEB-EVAL-01 evaluation
module.
Its hardware specifications are:
* 512MB DDR3 memory
* 512MB NAND flash
* Dual 10/100 Ethernet
* USB Host and USB OTG
* RS232
* MicroSD external storage
* Audio, RS232, I2C, SPI, CAN headers
* Further I/O options via A/V and Expansion headers
Signed-off-by: Martyn Welch
---
Changes in v2:
- Corrected spacing, ordering and naming
- Corrected ecspi3 chip selects
- Updated deprecated node
- Removed unneeded nodes
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/imx6ul-phytec-pcl063.dtsi | 149
.../boot/dts/imx6ul-phytec-peb-eval-01.dtsi | 55 +++
.../dts/imx6ul-phytec-phyboard-segin-full.dts | 96 +
.../dts/imx6ul-phytec-phyboard-segin.dtsi | 330 ++
5 files changed, 631 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ul-phytec-pcl063.dtsi
create mode 100644 arch/arm/boot/dts/imx6ul-phytec-peb-eval-01.dtsi
create mode 100644 arch/arm/boot/dts/imx6ul-phytec-phyboard-segin-full.dts
create mode 100644 arch/arm/boot/dts/imx6ul-phytec-phyboard-segin.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index bd40148a15b2..d35a0bf7b8f8 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -561,6 +561,7 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-opos6uldev.dtb \
imx6ul-pico-hobbit.dtb \
imx6ul-pico-pi.dtb \
+ imx6ul-phytec-phyboard-segin-full.dtb \
imx6ul-tx6ul-0010.dtb \
imx6ul-tx6ul-0011.dtb \
imx6ul-tx6ul-mainboard.dtb \
diff --git a/arch/arm/boot/dts/imx6ul-phytec-pcl063.dtsi
b/arch/arm/boot/dts/imx6ul-phytec-pcl063.dtsi
new file mode 100644
index ..03c194c89fa7
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-phytec-pcl063.dtsi
@@ -0,0 +1,149 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016 PHYTEC Messtechnik GmbH
+ * Author: Christian Hemp
+ */
+
+#include
+#include
+#include
+#include "imx6ul.dtsi"
+
+/ {
+ model = "Phytec phyCORE i.MX6 UltraLite";
+ compatible = "phytec,imx6ul-pcl063", "fsl,imx6ul";
+
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ /*
+* Set the minimum memory size here and
+* let the bootloader set the real size.
+*/
+ memory {
+ reg = <0x8000 0x800>;
+ };
+
+ gpio_leds_som: leds {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpioleds_som>;
+ compatible = "gpio-leds";
+
+ led_green {
+ label = "phycore:green";
+ gpios = <&gpio5 4 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+};
+
+&fec1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet1>;
+ phy-mode = "rmii";
+ phy-handle = <ðphy0>;
+ status = "okay";
+
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@1 {
+ reg = <1>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+ micrel,led-mode = <1>;
+ clocks = <&clks IMX6UL_CLK_ENET_REF>;
+ clock-names = "rmii-ref";
+ };
+ };
+};
+
+&gpmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpmi_nand>;
+ nand-on-flash-bbt;
+ status = "okay";
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 =<&pinctrl_i2c1>;
+ clock-frequency = <10>;
+ status = "okay";
+
+ eeprom@52 {
+ compatible = "catalyst,24c32", "atmel,24c32";
+ reg = <0x52>;
+ };
+};
+
+&snvs_poweroff {
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+
+ pinctrl_enet1: enet1grp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO07__ENET1_MDC 0x1b0b0
+ MX6UL_PAD_GPIO1_IO06__ENET1_MDIO0x1b0b0
+ MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b0b0
+ MX6UL_PAD_EN
Re: [PATCH v2 2/2] ARM: dts: imx6: Add support for Phytec phyBOARD i.MX6UL Segin
Hi Fabio,
On Fri, 2019-01-18 at 19:18 -0200, Fabio Estevam wrote:
> diff --git a/arch/arm/boot/dts/imx6ul-phytec-phyboard-segin-
> > full.dts b/arch/arm/boot/dts/imx6ul-phytec-phyboard-segin-full.dts
> > new file mode 100644
> > index ..83cdf4fa10c0
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/imx6ul-phytec-phyboard-segin-full.dts
> > @@ -0,0 +1,96 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2016 PHYTEC Messtechnik GmbH
> > + * Author: Christian Hemp
> > + */
> > +
> > +/dts-v1/;
> > +#include "imx6ul-phytec-pcl063.dtsi"
> > +#include "imx6ul-phytec-phyboard-segin.dtsi"
> > +#include "imx6ul-phytec-peb-eval-01.dtsi"
> > +
> > +/ {
> > + model = "Phytec phyBOARD-Segin i.MX6 UltraLite Full
> > Featured";
> > + compatible = "phytec,imx6ul-pbacd10", "phytec,imx6ul-
> > pcl063",
> > +"fsl,imx6ul";
>
> Better keep it in a single line?
>
It makes it longer than 80 chars, but I'm not adverse to that.
> > +&ecspi3 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_ecspi3>;
> > + cs-gpios = <&gpio1 20 GPIO_ACTIVE_HIGH>;
> > + status = "okay";
> > +
> > + spidev@0 {
> > + compatible = "spidev";
>
> Doesn't the kernel complain about spidev dts nodes?
>
Oh, yes, it does when spidev is loaded...
Removing.
Martyn
[PATCH v3 1/2] dt-bindings: Add vendor prefix for Catalyst Semiconductor
Add vendor prefix "catalyst" for Catalyst Semiconductor which is already in use but undocumented. Signed-off-by: Martyn Welch Reviewed-by: Rob Herring --- Changes in v3: - Add full stop to denote abbreviation. Changes in v2: None 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 389508584f48..a81de3134724 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -65,6 +65,7 @@ bticino Bticino International calxedaCalxeda capellaCapella Microsystems, Inc cascodaCascoda, Ltd. +catalyst Catalyst Semiconductor, Inc. cavium Cavium, Inc. cdns Cadence Design Systems Inc. cdtech CDTech(H.K.) Electronics Limited -- 2.20.1
[PATCH v3 2/2] ARM: dts: imx6: Add support for Phytec phyBOARD i.MX6UL Segin
The Phytec phyBOARD Segin is i.MX6 based SBC, available with either an
i.MX6UL or i.MX6ULL SOM and various add-on boards.
The following adds support for the "Full Featured" version of the Segin,
which is provided with the i.MX6UL SOM and the PEB-EVAL-01 evaluation
module.
Its hardware specifications are:
* 512MB DDR3 memory
* 512MB NAND flash
* Dual 10/100 Ethernet
* USB Host and USB OTG
* RS232
* MicroSD external storage
* Audio, RS232, I2C, SPI, CAN headers
* Further I/O options via A/V and Expansion headers
Signed-off-by: Martyn Welch
---
Changes in v3:
- Add memory device_type property
- Remove unneeded pinctrl-names property
- Keep compatible string on a single line
- Make node names generic and labels specific
Changes in v2:
- Corrected spacing, ordering and naming
- Corrected ecspi3 chip selects
- Updated deprecated node
- Removed unneeded nodes
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/imx6ul-phytec-pcl063.dtsi | 148
.../boot/dts/imx6ul-phytec-peb-eval-01.dtsi | 55 +++
.../dts/imx6ul-phytec-phyboard-segin-full.dts | 89 +
.../dts/imx6ul-phytec-phyboard-segin.dtsi | 329 ++
5 files changed, 622 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ul-phytec-pcl063.dtsi
create mode 100644 arch/arm/boot/dts/imx6ul-phytec-peb-eval-01.dtsi
create mode 100644 arch/arm/boot/dts/imx6ul-phytec-phyboard-segin-full.dts
create mode 100644 arch/arm/boot/dts/imx6ul-phytec-phyboard-segin.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index bd40148a15b2..d35a0bf7b8f8 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -561,6 +561,7 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-opos6uldev.dtb \
imx6ul-pico-hobbit.dtb \
imx6ul-pico-pi.dtb \
+ imx6ul-phytec-phyboard-segin-full.dtb \
imx6ul-tx6ul-0010.dtb \
imx6ul-tx6ul-0011.dtb \
imx6ul-tx6ul-mainboard.dtb \
diff --git a/arch/arm/boot/dts/imx6ul-phytec-pcl063.dtsi
b/arch/arm/boot/dts/imx6ul-phytec-pcl063.dtsi
new file mode 100644
index ..fc2997449b49
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-phytec-pcl063.dtsi
@@ -0,0 +1,148 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016 PHYTEC Messtechnik GmbH
+ * Author: Christian Hemp
+ */
+
+#include
+#include
+#include
+#include "imx6ul.dtsi"
+
+/ {
+ model = "Phytec phyCORE i.MX6 UltraLite";
+ compatible = "phytec,imx6ul-pcl063", "fsl,imx6ul";
+
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ /*
+* Set the minimum memory size here and
+* let the bootloader set the real size.
+*/
+ memory {
+ device_type = "memory";
+ reg = <0x8000 0x800>;
+ };
+
+ gpio_leds_som: leds {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpioleds_som>;
+ compatible = "gpio-leds";
+
+ led_green {
+ label = "phycore:green";
+ gpios = <&gpio5 4 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+};
+
+&fec1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet1>;
+ phy-mode = "rmii";
+ phy-handle = <ðphy0>;
+ status = "okay";
+
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@1 {
+ reg = <1>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+ micrel,led-mode = <1>;
+ clocks = <&clks IMX6UL_CLK_ENET_REF>;
+ clock-names = "rmii-ref";
+ };
+ };
+};
+
+&gpmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpmi_nand>;
+ nand-on-flash-bbt;
+ status = "okay";
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 =<&pinctrl_i2c1>;
+ clock-frequency = <10>;
+ status = "okay";
+
+ eeprom@52 {
+ compatible = "catalyst,24c32", "atmel,24c32";
+ reg = <0x52>;
+ };
+};
+
+&snvs_poweroff {
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_enet1: enet1grp {
+ fsl,pins = <
+ MX6UL_PAD_GP
[PATCH v4 1/2] dt-bindings: Add binding document for NOA1305
Document the ON Semiconductor NOA1305 ambient light sensor devicetree
bindings.
Signed-off-by: Martyn Welch
Reviewed-by: Rob Herring
---
Changes:
v2: Same as v1.
v3: Same as v2.
v4: Same as v3.
.../bindings/iio/light/noa1305.yaml | 44 +++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/light/noa1305.yaml
diff --git a/Documentation/devicetree/bindings/iio/light/noa1305.yaml
b/Documentation/devicetree/bindings/iio/light/noa1305.yaml
new file mode 100644
index ..17e7f140b69b
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/noa1305.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/noa1305.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ON Semiconductor NOA1305 Ambient Light Sensor
+
+maintainers:
+ - Martyn Welch
+
+description: |
+ Ambient sensing with an i2c interface.
+
+ https://www.onsemi.com/pub/Collateral/NOA1305-D.PDF
+
+properties:
+ compatible:
+enum:
+ - onnn,noa1305
+
+ reg:
+maxItems: 1
+
+ vin-supply:
+description: Regulator that provides power to the sensor
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+i2c {
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+light@39 {
+compatible = "onnn,noa1305";
+reg = <0x39>;
+};
+};
+...
--
2.20.1
[PATCH v4 2/2] iio: light: noa1305: Add support for NOA1305
This driver adds the initial support for the ON Semiconductor
NOA1305 Ambient Light Sensor.
Originally written by Sergei Miroshnichenko. Found here:
https://github.com/EmcraftSystems/linux-upstream/commit/196d6cf897e632d2cb82d45484bd7a1bfdd5b6d9
Signed-off-by: Sergei M
Signed-off-by: Martyn Welch
---
Changes:
v2:
- Correcting authorship and SOB.
v3:
- Improve register define naming.
- Follow IIO convention of interleaving register bit definitions with
register defintions.
- Use proper endian swapping.
- Process raw sensor count into Lux.
- Avoid setting variables to zero when not needed.
- Check return value of i2c writes.
- Implement disabling of regulator as a devm action.
- Remove excessive white spacing.
v4:
- Clean up returns
- Remove redundant noa1305_remove()
- Remove redundant interrupt configuration/disabling
- Return raw value and scaling
Note: Scaling added for all possible interation times to ensure the
mechanism utilised would allow this, though chip currently
statically configured to 800mS.
drivers/iio/light/Kconfig | 10 ++
drivers/iio/light/Makefile | 1 +
drivers/iio/light/noa1305.c | 312
3 files changed, 323 insertions(+)
create mode 100644 drivers/iio/light/noa1305.c
diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index 954c958cfc43..d1db0ec0d0f5 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -309,6 +309,16 @@ config MAX44009
To compile this driver as a module, choose M here:
the module will be called max44009.
+config NOA1305
+ tristate "ON Semiconductor NOA1305 ambient light sensor"
+ depends on I2C
+ help
+Say Y here if you want to build support for the ON Semiconductor
+NOA1305 ambient light sensor.
+
+To compile this driver as a module, choose M here:
+The module will be called noa1305.
+
config OPT3001
tristate "Texas Instruments OPT3001 Light Sensor"
depends on I2C
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index e40794fbb435..00d1f9b98f39 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_LTR501) += ltr501.o
obj-$(CONFIG_LV0104CS) += lv0104cs.o
obj-$(CONFIG_MAX44000) += max44000.o
obj-$(CONFIG_MAX44009) += max44009.o
+obj-$(CONFIG_NOA1305) += noa1305.o
obj-$(CONFIG_OPT3001) += opt3001.o
obj-$(CONFIG_PA12203001) += pa12203001.o
obj-$(CONFIG_RPR0521) += rpr0521.o
diff --git a/drivers/iio/light/noa1305.c b/drivers/iio/light/noa1305.c
new file mode 100644
index ..b8758aa7b32a
--- /dev/null
+++ b/drivers/iio/light/noa1305.c
@@ -0,0 +1,312 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Support for ON Semiconductor NOA1305 ambient light sensor
+ *
+ * Copyright (C) 2016 Emcraft Systems
+ * Copyright (C) 2019 Collabora Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define NOA1305_REG_POWER_CONTROL 0x0
+#define NOA1305_POWER_CONTROL_DOWN 0x00
+#define NOA1305_POWER_CONTROL_ON 0x08
+#define NOA1305_REG_RESET 0x1
+#define NOA1305_RESET_RESET 0x10
+#define NOA1305_REG_INTEGRATION_TIME 0x2
+#define NOA1305_INTEGR_TIME_800MS0x00
+#define NOA1305_INTEGR_TIME_400MS0x01
+#define NOA1305_INTEGR_TIME_200MS0x02
+#define NOA1305_INTEGR_TIME_100MS0x03
+#define NOA1305_INTEGR_TIME_50MS 0x04
+#define NOA1305_INTEGR_TIME_25MS 0x05
+#define NOA1305_INTEGR_TIME_12_5MS 0x06
+#define NOA1305_INTEGR_TIME_6_25MS 0x07
+#define NOA1305_REG_INT_SELECT 0x3
+#define NOA1305_INT_SEL_ACTIVE_HIGH 0x01
+#define NOA1305_INT_SEL_ACTIVE_LOW 0x02
+#define NOA1305_INT_SEL_INACTIVE 0x03
+#define NOA1305_REG_INT_THRESH_LSB 0x4
+#define NOA1305_REG_INT_THRESH_MSB 0x5
+#define NOA1305_REG_ALS_DATA_LSB 0x6
+#define NOA1305_REG_ALS_DATA_MSB 0x7
+#define NOA1305_REG_DEVICE_ID_LSB 0x8
+#define NOA1305_REG_DEVICE_ID_MSB 0x9
+
+#define NOA1305_DEVICE_ID 0x0519
+#define NOA1305_DRIVER_NAME"noa1305"
+
+struct noa1305_priv {
+ struct i2c_client *client;
+ struct regmap *regmap;
+ struct regulator *vin_reg;
+};
+
+static int noa1305_measure(struct noa1305_priv *priv)
+{
+ __le16 data;
+ int ret;
+
+ ret = regmap_bulk_read(priv->regmap, NOA1305_REG_ALS_DATA_LSB, &data,
+ 2);
+ if (ret < 0)
+ return ret;
+
+ return le16_to_cpu(data);
+}
+
+static int noa1305_scale(struct noa1305_priv *priv, int *val, int *val2)
+{
+ int data;
+ int ret;
+
+ ret = regmap_read(priv->regmap, NOA1305_REG_INTEGRATION_TIME, &data);
+ if (ret < 0)
+ return ret;
+
+ /*
+* Lux = count / ( *
[PATCH 1/2] dt-bindings: Add binding document for NOA1305
Document the ON Semiconductor NOA1305 ambient light sensor devicetree
bindings.
Signed-off-by: Martyn Welch
---
.../bindings/iio/light/noa1305.yaml | 44 +++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/light/noa1305.yaml
diff --git a/Documentation/devicetree/bindings/iio/light/noa1305.yaml
b/Documentation/devicetree/bindings/iio/light/noa1305.yaml
new file mode 100644
index ..17e7f140b69b
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/noa1305.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/noa1305.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ON Semiconductor NOA1305 Ambient Light Sensor
+
+maintainers:
+ - Martyn Welch
+
+description: |
+ Ambient sensing with an i2c interface.
+
+ https://www.onsemi.com/pub/Collateral/NOA1305-D.PDF
+
+properties:
+ compatible:
+enum:
+ - onnn,noa1305
+
+ reg:
+maxItems: 1
+
+ vin-supply:
+description: Regulator that provides power to the sensor
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+i2c {
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+light@39 {
+compatible = "onnn,noa1305";
+reg = <0x39>;
+};
+};
+...
--
2.20.1
[PATCH 2/2] iio: light: noa1305: Add support for NOA1305
From: Martyn Welch
This driver adds the initial support for the ON Semiconductor
NOA1305 Ambient Light Sensor.
Originally written by Sergei Miroshnichenko. Found here:
https://github.com/EmcraftSystems/linux-upstream/commit/196d6cf897e632d2cb82d45484bd7a1bfdd5b6d9
Signed-off-by: Sergei M
Signed-off-by: Martyn Welch
---
drivers/iio/light/Kconfig | 10 ++
drivers/iio/light/Makefile | 1 +
drivers/iio/light/noa1305.c | 247
3 files changed, 258 insertions(+)
create mode 100644 drivers/iio/light/noa1305.c
diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index 954c958cfc43..d1db0ec0d0f5 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -309,6 +309,16 @@ config MAX44009
To compile this driver as a module, choose M here:
the module will be called max44009.
+config NOA1305
+ tristate "ON Semiconductor NOA1305 ambient light sensor"
+ depends on I2C
+ help
+Say Y here if you want to build support for the ON Semiconductor
+NOA1305 ambient light sensor.
+
+To compile this driver as a module, choose M here:
+The module will be called noa1305.
+
config OPT3001
tristate "Texas Instruments OPT3001 Light Sensor"
depends on I2C
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index e40794fbb435..00d1f9b98f39 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_LTR501) += ltr501.o
obj-$(CONFIG_LV0104CS) += lv0104cs.o
obj-$(CONFIG_MAX44000) += max44000.o
obj-$(CONFIG_MAX44009) += max44009.o
+obj-$(CONFIG_NOA1305) += noa1305.o
obj-$(CONFIG_OPT3001) += opt3001.o
obj-$(CONFIG_PA12203001) += pa12203001.o
obj-$(CONFIG_RPR0521) += rpr0521.o
diff --git a/drivers/iio/light/noa1305.c b/drivers/iio/light/noa1305.c
new file mode 100644
index ..2c65c5c2e09a
--- /dev/null
+++ b/drivers/iio/light/noa1305.c
@@ -0,0 +1,247 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Support for ON Semiconductor NOA1305 ambient light sensor
+ *
+ * Copyright (C) 2016 Emcraft Systems
+ * Copyright (C) 2019 Collabora Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define NOA1305_REG_POWER_CONTROL 0x0
+#define NOA1305_REG_RESET 0x1
+#define NOA1305_REG_INTEGRATION_TIME 0x2
+#define NOA1305_REG_INT_SELECT 0x3
+#define NOA1305_REG_INT_THRESH_LSB 0x4
+#define NOA1305_REG_INT_THRESH_MSB 0x5
+#define NOA1305_REG_ALS_DATA_LSB 0x6
+#define NOA1305_REG_ALS_DATA_MSB 0x7
+#define NOA1305_REG_DEVICE_ID_LSB 0x8
+#define NOA1305_REG_DEVICE_ID_MSB 0x9
+
+#define NOA1305_DEVICE_ID 0x0519
+
+#define NOA1305_POWER_ON 0x08
+#define NOA1305_POWER_DOWN 0x00
+#define NOA1305_RESET 0x10
+
+#define NOA1305_INT_ACTIVE_HIGH0x01
+#define NOA1305_INT_ACTIVE_LOW 0x02
+#define NOA1305_INT_INACTIVE 0x03
+
+#define NOA1305_INTEGR_TIME_800MS 0x00
+#define NOA1305_INTEGR_TIME_400MS 0x01
+#define NOA1305_INTEGR_TIME_200MS 0x02
+#define NOA1305_INTEGR_TIME_100MS 0x03
+#define NOA1305_INTEGR_TIME_50MS 0x04
+#define NOA1305_INTEGR_TIME_25MS 0x05
+#define NOA1305_INTEGR_TIME_12_5MS 0x06
+#define NOA1305_INTEGR_TIME_6_25MS 0x07
+
+#define NOA1305_DRIVER_NAME"noa1305"
+
+struct noa1305_priv {
+ struct i2c_client *client;
+ struct regmap *regmap;
+ struct regulator *vin_reg;
+};
+
+static int noa1305_measure(struct noa1305_priv *priv)
+{
+ u8 data[2];
+ int ret;
+
+ ret = regmap_bulk_read(priv->regmap, NOA1305_REG_ALS_DATA_LSB, data,
+ 2);
+ if (ret < 0)
+ return ret;
+
+ return (data[1] << 8) | data[0];
+}
+
+static const struct iio_chan_spec noa1305_channels[] = {
+ {
+ .type = IIO_LIGHT,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+ }
+};
+
+static int noa1305_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long mask)
+{
+ int ret = -EINVAL;
+ struct noa1305_priv *priv = iio_priv(indio_dev);
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ switch (chan->type) {
+ case IIO_LIGHT:
+ ret = noa1305_measure(priv);
+ if (ret < 0)
+ return ret;
+ *val = ret;
+ ret = IIO_VAL_INT;
+ break;
+ default:
+ break;
+ }
+ break;
+ default:
+ break;
+ }
+
+ return ret;
[PATCH v2 2/2] iio: light: noa1305: Add support for NOA1305
This driver adds the initial support for the ON Semiconductor
NOA1305 Ambient Light Sensor.
Originally written by Sergei Miroshnichenko. Found here:
https://github.com/EmcraftSystems/linux-upstream/commit/196d6cf897e632d2cb82d45484bd7a1bfdd5b6d9
Signed-off-by: Sergei M
Signed-off-by: Martyn Welch
---
Changes:
v2: Correcting authorship and SOB.
drivers/iio/light/Kconfig | 10 ++
drivers/iio/light/Makefile | 1 +
drivers/iio/light/noa1305.c | 247
3 files changed, 258 insertions(+)
create mode 100644 drivers/iio/light/noa1305.c
diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index 954c958cfc43..d1db0ec0d0f5 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -309,6 +309,16 @@ config MAX44009
To compile this driver as a module, choose M here:
the module will be called max44009.
+config NOA1305
+ tristate "ON Semiconductor NOA1305 ambient light sensor"
+ depends on I2C
+ help
+Say Y here if you want to build support for the ON Semiconductor
+NOA1305 ambient light sensor.
+
+To compile this driver as a module, choose M here:
+The module will be called noa1305.
+
config OPT3001
tristate "Texas Instruments OPT3001 Light Sensor"
depends on I2C
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index e40794fbb435..00d1f9b98f39 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_LTR501) += ltr501.o
obj-$(CONFIG_LV0104CS) += lv0104cs.o
obj-$(CONFIG_MAX44000) += max44000.o
obj-$(CONFIG_MAX44009) += max44009.o
+obj-$(CONFIG_NOA1305) += noa1305.o
obj-$(CONFIG_OPT3001) += opt3001.o
obj-$(CONFIG_PA12203001) += pa12203001.o
obj-$(CONFIG_RPR0521) += rpr0521.o
diff --git a/drivers/iio/light/noa1305.c b/drivers/iio/light/noa1305.c
new file mode 100644
index ..2c65c5c2e09a
--- /dev/null
+++ b/drivers/iio/light/noa1305.c
@@ -0,0 +1,247 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Support for ON Semiconductor NOA1305 ambient light sensor
+ *
+ * Copyright (C) 2016 Emcraft Systems
+ * Copyright (C) 2019 Collabora Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define NOA1305_REG_POWER_CONTROL 0x0
+#define NOA1305_REG_RESET 0x1
+#define NOA1305_REG_INTEGRATION_TIME 0x2
+#define NOA1305_REG_INT_SELECT 0x3
+#define NOA1305_REG_INT_THRESH_LSB 0x4
+#define NOA1305_REG_INT_THRESH_MSB 0x5
+#define NOA1305_REG_ALS_DATA_LSB 0x6
+#define NOA1305_REG_ALS_DATA_MSB 0x7
+#define NOA1305_REG_DEVICE_ID_LSB 0x8
+#define NOA1305_REG_DEVICE_ID_MSB 0x9
+
+#define NOA1305_DEVICE_ID 0x0519
+
+#define NOA1305_POWER_ON 0x08
+#define NOA1305_POWER_DOWN 0x00
+#define NOA1305_RESET 0x10
+
+#define NOA1305_INT_ACTIVE_HIGH0x01
+#define NOA1305_INT_ACTIVE_LOW 0x02
+#define NOA1305_INT_INACTIVE 0x03
+
+#define NOA1305_INTEGR_TIME_800MS 0x00
+#define NOA1305_INTEGR_TIME_400MS 0x01
+#define NOA1305_INTEGR_TIME_200MS 0x02
+#define NOA1305_INTEGR_TIME_100MS 0x03
+#define NOA1305_INTEGR_TIME_50MS 0x04
+#define NOA1305_INTEGR_TIME_25MS 0x05
+#define NOA1305_INTEGR_TIME_12_5MS 0x06
+#define NOA1305_INTEGR_TIME_6_25MS 0x07
+
+#define NOA1305_DRIVER_NAME"noa1305"
+
+struct noa1305_priv {
+ struct i2c_client *client;
+ struct regmap *regmap;
+ struct regulator *vin_reg;
+};
+
+static int noa1305_measure(struct noa1305_priv *priv)
+{
+ u8 data[2];
+ int ret;
+
+ ret = regmap_bulk_read(priv->regmap, NOA1305_REG_ALS_DATA_LSB, data,
+ 2);
+ if (ret < 0)
+ return ret;
+
+ return (data[1] << 8) | data[0];
+}
+
+static const struct iio_chan_spec noa1305_channels[] = {
+ {
+ .type = IIO_LIGHT,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+ }
+};
+
+static int noa1305_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long mask)
+{
+ int ret = -EINVAL;
+ struct noa1305_priv *priv = iio_priv(indio_dev);
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ switch (chan->type) {
+ case IIO_LIGHT:
+ ret = noa1305_measure(priv);
+ if (ret < 0)
+ return ret;
+ *val = ret;
+ ret = IIO_VAL_INT;
+ break;
+ default:
+ break;
+ }
+ break;
+ default:
+ break;
+
[PATCH v2 1/2] dt-bindings: Add binding document for NOA1305
Document the ON Semiconductor NOA1305 ambient light sensor devicetree
bindings.
Signed-off-by: Martyn Welch
---
Changes:
v2: Same as v1.
.../bindings/iio/light/noa1305.yaml | 44 +++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/light/noa1305.yaml
diff --git a/Documentation/devicetree/bindings/iio/light/noa1305.yaml
b/Documentation/devicetree/bindings/iio/light/noa1305.yaml
new file mode 100644
index ..17e7f140b69b
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/noa1305.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/noa1305.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ON Semiconductor NOA1305 Ambient Light Sensor
+
+maintainers:
+ - Martyn Welch
+
+description: |
+ Ambient sensing with an i2c interface.
+
+ https://www.onsemi.com/pub/Collateral/NOA1305-D.PDF
+
+properties:
+ compatible:
+enum:
+ - onnn,noa1305
+
+ reg:
+maxItems: 1
+
+ vin-supply:
+description: Regulator that provides power to the sensor
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+i2c {
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+light@39 {
+compatible = "onnn,noa1305";
+reg = <0x39>;
+};
+};
+...
--
2.20.1
Re: [PATCH] ARM: dts: am335x: Add support for Bosch Guardian
On Tue, 2019-02-12 at 10:49 -0800, Tony Lindgren wrote: > Hi, > > * Martyn Welch [190211 04:27]: > > The Bosch Guardian is a TI am335x based device. > > > > It's hardware specifications are as follows: > > > > * 256 MB DDR3 memory > > * 512 MB NAND Flash > > * USB OTG > > * RS232 > > * MicroSD external storage > > * LCD Display interface > > Thanks applying into omap-for-v5.1/dt. > Thanks Tony. > Do you have some link for this device for more > information? > I'm not aware of any publicly available documentation at this time. > > +/include/ "tps65217.dtsi" > > I'll update this to use #include "tps65217.dtsi" > while applying. > OK, I found examples of both, guess I picked the wrong one :-) Martyn > Regards, > > Tony
Re: [PATCH] vme: remove unneeded kfree
On Thu, 2018-09-06 at 22:04 -0700, Linus Torvalds wrote:
> On Thu, Sep 6, 2018 at 1:51 AM Ding Xiang
> wrote:
> >
> > put_device will call vme_dev_release to free vdev, kfree is
> > unnecessary here.
>
> That does seem to be the case. I think "unnecessary" is overly kind,
> it does seem to be a double free.
>
> Looks like the issue was introduced back in 2013 by commit
> def1820d25fa ("vme: add missing put_device() after device_register()
> fails").
>
> It seems you should *either* kfree() the vdev, _or_ do put_device(),
> but doing both seems wrong.
>
> I presume the device_register() has never failed, and this being
> vme-only I'm guessing there isn't a vibrant testing community.
>
I think that is also overly kind :-)
I currently lack access to suitable hardware to test fully myself and I
need to find some time to (re)implement some automated testing, after I
lost access to the bits I had when I left a previous employer. That and
see if I can get access to some hardware again...
Manohar, do you still have access/interest in the VME stuff? You've
been very quiet for a long time now.
Martyn
Re: VME: devices not removed after commit 050c3d52cc7
On Fri, Jan 13, 2017 at 05:28:37PM +0100, Stefano Babic wrote:
> Hi Paul,
>
> On 13/01/2017 16:39, Paul Gortmaker wrote:
> > [Adding Martyn to Cc]
> >
>
> Sorry, I forgot to run get_maintainer before posting :-)
>
No worries, and sorry for the delay, this ended up in my spam filter :-/
> > [VME: devices not removed after commit 050c3d52cc7] On 13/01/2017 (Fri
> > 11:03) Stefano Babic wrote:
> >
> >> Hi,
> >>
> >> I have updated a custom VME device driver (mainly based on vme_user.c)
> >> to 4.9 (previously it was for 3.14-).
> >>
> >> I see that VME device drivers cannot be loaded and unloaded due to this
> >> commit:
> >>
> >> commit 050c3d52cc7810d9d17b8cd231708609af6876ae
> >> Author: Paul Gortmaker
> >> Date: Sun Jul 3 14:05:56 2016 -0400
> >>
> >> vme: make core vme support explicitly non-modular
> >
> > I've gone back and looked at this, and vme_user.c and I'm not yet 100%
> > convinced this is the right conclusion. But perhaps, and I've put
> > Martyn on the Cc, in the hopes that he can clarify as well, if needed.
>
> Thanks. What I am seeing is that (*remove) in bus_type is called when a
> device is removed from the bus, and not when the bus is removed. This
> looks consistent with other busses. And in fact, the function was:
>
> static int vme_bus_remove(struct device *dev)
> {
>int retval = -ENODEV;
>struct vme_driver *driver;
>struct vme_dev *vdev = dev_to_vme_dev(dev);
>
>driver = dev->platform_data;
>
>if (driver->remove != NULL)
>retval = driver->remove(vdev);
>
> So this is the point where the remove for the VME's device is called, as
> far as I understand.
>
>
Yup, I agree - we need to re-instate this function, it's called when a
device driver is removed.
Thanks for noticing this, it's been a while since I wrote this code and
the patch /looked/ sane...
Martyn
> >
> >>
> >>
> >> In fact, this drops the remove function, that scans all devices attached
> >> to the bus and call their remove function.
> >
> > So I guess my confusion here is between removal of a VME device, vs. the
> > removal of a complete VME bus.
>
> Right, this is what must be cleared. In my understanding, the dropped
> remove function is called when a device is removed from the bus, that
> leads to the fact that the VME's device is not cleaned unloaded.
>
> > The above commit you reference was based
> > on the premise that removal of a VME bus is not supported.
>
> Agree, and I fully agree that loading / unloading of VME makes less sense.
>
> > Which is not
> > to say that a VME device removal is not supported.
>
> I agree to reach this goal - just the dropped remove() is called IMHO
> when a device is dropped from the VME bus and not when the bus is
> removed from system. This is what we need to clarify here.
>
> >
> >>
> >> That means that "remove" entry points in VME device driver (let see in
> >> drivers/staging/vme/devices/vme_user.c) are now dead code and the
> >> required cleanup code is not called at all (devices and class are not
> >> removed). Reloading the same driver cause errors due to the missing
> >> cleanup by unloading. This does not let build VME device drivers as
> >> module, as it is supposed to be done.
> >
> > Again, I don't think this analysis is 100% right, but I can't be sure
> > because your driver is out of tree and I don't know what it does
> > precisely. Looking at vme_user.c example, it has its own .remove
> > function that should be executed at module unload, and that would do all
> > the cleanup (see vme_user_remove).
>
> In my test, vme_user's remove is never called with the patch applied.
> Reverting the patch, it works again, and remove is called: loading /
> unloading of VME's device drivers works again.
>
> >
> >>
> >> Paul, what do you mind ?
> >
> > For sure, we can restore the .remove and vme_bus_remove portions of that
> > commit if it is a real regression against a correct use of the
> > infrastructure,
>
> I absolutely agree that we have to clarify the point before doing something.
>
> > but I'm still not clear how you'd be triggering the
> > vme_bus_remove unless the vme device driver was going up into its
> > parent's bus struct directly.
>
> No, this is not done !
>
> > Maybe Martyn can spot where I've
> > misunderstood the bus vs. device separation here.
> >
>
>
> Best regards,
> Stefano
>
>
>
> --
> =
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
> =
Re: [PATCH 2/2] watchdog: ziirave_wdt: Add support to upload the firmware.
Few comments inline
On 17/06/16 11:52, Enric Balletbo i Serra wrote:
This patch adds and entry to the sysfs to start firmware upload process
on the specified device with the requested firmware.
The uploading of the firmware needs only to happen once per firmware
upgrade, as the firmware is stored in persistent storage. If the
firmware upload or the firmware verification fails then we print and
error message and exit.
Signed-off-by: Enric Balletbo i Serra
---
drivers/watchdog/ziirave_wdt.c | 426 +
1 file changed, 426 insertions(+)
diff --git a/drivers/watchdog/ziirave_wdt.c b/drivers/watchdog/ziirave_wdt.c
index fa1efef..63e81bc 100644
--- a/drivers/watchdog/ziirave_wdt.c
+++ b/drivers/watchdog/ziirave_wdt.c
@@ -18,7 +18,10 @@
* GNU General Public License for more details.
*/
+#include
+#include
#include
+#include
#include
#include
#include
@@ -36,6 +39,8 @@
#define ZIIRAVE_STATE_OFF 0x1
#define ZIIRAVE_STATE_ON 0x2
+#define ZIIRAVE_FW_NAME"ziirave_fw.hex"
+
static char *ziirave_reasons[] = {"power cycle", "hw watchdog", NULL, NULL,
"host request", NULL, "illegal configuration",
"illegal instruction", "illegal trap",
@@ -50,6 +55,30 @@ static char *ziirave_reasons[] = {"power cycle", "hw
watchdog", NULL, NULL,
#define ZIIRAVE_WDT_PING 0x9
#define ZIIRAVE_WDT_RESET_DURATION0xa
+#define ZIIRAVE_FIRM_PKT_TOTAL_SIZE20
+#define ZIIRAVE_FIRM_PKT_DATA_SIZE 16
+#define ZIIRAVE_FIRM_FLASH_MEMORY_START0x1600
+#define ZIIRAVE_FIRM_FLASH_MEMORY_END 0x2bbf
This doesn't seem to be used anywhere:
+/* Download message error. Ex: Message did not CRC properly */
+#define ZIIRAVE_FIRM_DOWNLOAD_NAK 0
+/* Received and ready for next Download packet. */
+#define ZIIRAVE_FIRM_DOWNLOAD_ACK 1
+/* Currently writing to flash. Retry Download status in a moment! */
+#define ZIIRAVE_FIRM_DOWNLOAD_BUSY 2
Neither is this:
+/* Hardware error writing flash has occurred! */
+#define ZIIRAVE_FIRM_DOWNLOAD_FAIL 3
+
+/*
+ * Firmware commands
+ */
+#define ZIIRAVE_CMD_DOWNLOAD_START 0x10
+#define ZIIRAVE_CMD_DOWNLOAD_END 0x11
+#define ZIIRAVE_CMD_DOWNLOAD_SET_READ_ADDR 0x12
+#define ZIIRAVE_CMD_DOWNLOAD_READ_BYTE 0x13
+#define ZIIRAVE_CMD_RESET_PROCESSOR0x0b
+#define ZIIRAVE_CMD_JUMP_TO_BOOTLOADER 0x0c
+#define ZIIRAVE_CMD_DOWNLOAD_PACKET0x0e
+
struct ziirave_wdt_rev {
unsigned char major;
unsigned char minor;
@@ -62,6 +91,23 @@ struct ziirave_wdt_data {
int reset_reason;
};
+/*
+ * A packet to send to the firmware is composed by following bytes:
+ * Count | Addr0 | Addr1 | Data0 .. Data15 | Checksum |
+ * Where,
Would "Length" below be the same as "Count" above?
+ * Length: A data byte containing the length of the data.
+ * Addr0: Low byte of the address.
+ * Addr1: High byte of the address.
+ * Data0 .. Data15: Array of 16 bytes of data.
+ * Checksum: Checksum byte to verify data integrity.
+ */
+struct ziirave_fw_pkt_t {
+ u8 length;
+ u16 addr;
+ u8 data[ZIIRAVE_FIRM_PKT_DATA_SIZE];
+ u8 checksum;
+} __packed;
+
static int wdt_timeout;
module_param(wdt_timeout, int, 0);
MODULE_PARM_DESC(wdt_timeout, "Watchdog timeout in seconds");
@@ -146,6 +192,339 @@ static unsigned int ziirave_wdt_get_timeleft(struct
watchdog_device *wdd)
return ret;
}
+static int ziirave_firm_wait_for_ack(struct watchdog_device *wdd)
+{
+ struct i2c_client *client = to_i2c_client(wdd->parent);
+ int ret;
+
+ do {
+ usleep_range(5000, 5100);
+ ret = i2c_smbus_read_byte(client);
+ if (ret < 0) {
+ dev_err(&client->dev, "Failed to read byte\n");
+ return ret;
+ }
+ } while (ret == ZIIRAVE_FIRM_DOWNLOAD_BUSY);
+
+ return ret == ZIIRAVE_FIRM_DOWNLOAD_ACK ? 0 : -EIO;
Is the required response the same for a NAK and FAIL?
+}
+
+/*
+ * Parse Microchip format Hex file (an extended Intel Hex file) to extract
+ * address and data.
+ */
+static int ziirave_firm_parse_hex_line(unsigned char *fw_data,
+ struct ziirave_fw_pkt_t *fw_pkt,
+ bool *addr_has_changed)
+{
+ int count = 0;
+ unsigned char *src, dst;
+
+ if (*fw_data++ != ':')
+ return -EFAULT;
+
+ /* locate end of line */
+ for (src = fw_data; *src != '\n'; src += 2) {
+ /*
+* Convert the ascii hexadecimal string to its binary
+* representation
+*/
+ if (hex2bin(&dst, src, 1))
+ return -EINVAL;
+
+ /* Parse line to split addr / data */
+ switch (count) {
+
Re: [PATCH] vme: make core vme support explicitly non-modular
On 03/07/16 19:05, Paul Gortmaker wrote:
The Kconfig currently controlling compilation of this code is:
drivers/vme/Kconfig:menuconfig VME_BUS
drivers/vme/Kconfig:bool "VME bridge support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.
We replace module.h and moduleparam.h (unused) with init.h and also
export.h ; the latter since this file does export some syms.
Since this is a struct bus_type and not a platform_driver, we don't
have any ".suppress_bind_attrs" to be concerned about when we
drop the ".remove" code from this file.
Since module_init was not in use by this code, the init ordering
remains unchanged with this commit.
Cc: Martyn Welch
Cc: Manohar Vanga
Cc: Greg Kroah-Hartman
Cc: de...@driverdev.osuosl.org
Signed-off-by: Paul Gortmaker
Acked-by: Martyn Welch
---
drivers/vme/vme.c | 27 ++-
1 file changed, 2 insertions(+), 25 deletions(-)
diff --git a/drivers/vme/vme.c b/drivers/vme/vme.c
index 37ac0a58e59a..557149f0f88a 100644
--- a/drivers/vme/vme.c
+++ b/drivers/vme/vme.c
@@ -13,8 +13,8 @@
* option) any later version.
*/
-#include
-#include
+#include
+#include
#include
#include
#include
@@ -39,7 +39,6 @@ static unsigned int vme_bus_numbers;
static LIST_HEAD(vme_bus_list);
static DEFINE_MUTEX(vme_buses_lock);
-static void __exit vme_exit(void);
static int __init vme_init(void);
static struct vme_dev *dev_to_vme_dev(struct device *dev)
@@ -1622,25 +1621,10 @@ static int vme_bus_probe(struct device *dev)
return retval;
}
-static int vme_bus_remove(struct device *dev)
-{
- int retval = -ENODEV;
- struct vme_driver *driver;
- struct vme_dev *vdev = dev_to_vme_dev(dev);
-
- driver = dev->platform_data;
-
- if (driver->remove != NULL)
- retval = driver->remove(vdev);
-
- return retval;
-}
-
struct bus_type vme_bus_type = {
.name = "vme",
.match = vme_bus_match,
.probe = vme_bus_probe,
- .remove = vme_bus_remove,
};
EXPORT_SYMBOL(vme_bus_type);
@@ -1648,11 +1632,4 @@ static int __init vme_init(void)
{
return bus_register(&vme_bus_type);
}
-
-static void __exit vme_exit(void)
-{
- bus_unregister(&vme_bus_type);
-}
-
subsys_initcall(vme_init);
-module_exit(vme_exit);
Re: [PATCH v2] [STYLE]staging:vme:vme_user.c Correct spelling mistakes
On Sun, Nov 13, 2016 at 08:28:34PM -0500, Walt Feasel wrote:
> Make spelling corrections for 'correctly' and
> 'unregister'.
>
> Signed-off-by: Walt Feasel
Acked-by: Martyn Welch
> ---
>
> Removed the previously submitted U.S. spelling for
> 'initialise' to keep the correct U.K. spelling.
>
> drivers/staging/vme/devices/vme_user.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/vme/devices/vme_user.c
> b/drivers/staging/vme/devices/vme_user.c
> index 5dd430f..2753fb2 100644
> --- a/drivers/staging/vme/devices/vme_user.c
> +++ b/drivers/staging/vme/devices/vme_user.c
> @@ -661,7 +661,7 @@ static int vme_user_probe(struct vme_dev *vdev)
> }
> class_destroy(vme_user_sysfs_class);
>
> - /* Ensure counter set correcty to unalloc all master windows */
> + /* Ensure counter set correctly to unalloc all master windows */
> i = MASTER_MAX + 1;
> err_master:
> while (i > MASTER_MINOR) {
> @@ -671,7 +671,7 @@ static int vme_user_probe(struct vme_dev *vdev)
> }
>
> /*
> - * Ensure counter set correcty to unalloc all slave windows and buffers
> + * Ensure counter set correctly to unalloc all slave windows and buffers
>*/
> i = SLAVE_MAX + 1;
> err_slave:
> @@ -716,7 +716,7 @@ static int vme_user_remove(struct vme_dev *dev)
> /* Unregister device driver */
> cdev_del(vme_user_cdev);
>
> - /* Unregiser the major and minor device numbers */
> + /* Unregister the major and minor device numbers */
> unregister_chrdev_region(MKDEV(VME_MAJOR, 0), VME_DEVS);
>
> return 0;
> --
> 2.1.4
>
Re: [PATCH] HID: Accutouch: Add driver for ELO Accutouch 2216 USB Touchscreens
This patch has been sitting on the list for about 2 weeks. Is there
anything wrong with this patch?
Thanks,
Martyn
On Tue, Feb 14, 2017 at 02:17:56PM +, Martyn Welch wrote:
> The Accutouch 2216 is reporting BTN_LEFT/BTN_MOUSE rather than BTM_TOUCH
> in it's capabilities, which is what user space expects a touchscreen
> device to report. This is causing udev to consider the device to be a
> "VMware's USB mouse" rather than as a touchscreen, which results in a
> mouse cursor being displayed in Weston.
>
> This patch adds a special driver for the device to correct the
> capabilities reported.
>
> Signed-off-by: Martyn Welch
> ---
> drivers/hid/Kconfig | 12 +++
> drivers/hid/Makefile| 1 +
> drivers/hid/hid-accutouch.c | 52
> +
> drivers/hid/hid-core.c | 1 +
> drivers/hid/hid-ids.h | 1 +
> 5 files changed, 67 insertions(+)
> create mode 100644 drivers/hid/hid-accutouch.c
>
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index 4070b73..ba0d17a 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -98,6 +98,18 @@ config HID_A4TECH
> ---help---
> Support for A4 tech X5 and WOP-35 / Trust 450L mice.
>
> +config HID_ACCUTOUCH
> + tristate "Accutouch touch device"
> + depends on USB_HID
> + ---help---
> + This selects a driver for the Accutouch 2216 touch controller.
> +
> + The driver works around a problem in the reported device capabilities
> + which causes userspace to detect the device as a mouse rather than
> + a touchscreen.
> +
> + Say Y here if you have a Accutouch 2216 touch controller.
> +
> config HID_ACRUX
> tristate "ACRUX game controller support"
> depends on HID
> diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
> index 4d111f2..48be3ed 100644
> --- a/drivers/hid/Makefile
> +++ b/drivers/hid/Makefile
> @@ -21,6 +21,7 @@ hid-wiimote-y := hid-wiimote-core.o
> hid-wiimote-modules.o
> hid-wiimote-$(CONFIG_DEBUG_FS) += hid-wiimote-debug.o
>
> obj-$(CONFIG_HID_A4TECH) += hid-a4tech.o
> +obj-$(CONFIG_HID_ACCUTOUCH) += hid-accutouch.o
> obj-$(CONFIG_HID_ALPS) += hid-alps.o
> obj-$(CONFIG_HID_ACRUX) += hid-axff.o
> obj-$(CONFIG_HID_APPLE) += hid-apple.o
> diff --git a/drivers/hid/hid-accutouch.c b/drivers/hid/hid-accutouch.c
> new file mode 100644
> index 000..4e28716
> --- /dev/null
> +++ b/drivers/hid/hid-accutouch.c
> @@ -0,0 +1,52 @@
> +/*
> + * HID driver for Elo Accutouch touchscreens
> + *
> + * Copyright (c) 2016, Collabora Ltd.
> + * Copyright (c) 2016, General Electric Company
> + *
> + * based on hid-penmount.c
> + * Copyright (c) 2014 Christian Gmeiner gmail.com>
> + */
> +
> +/*
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the Free
> + * Software Foundation; either version 2 of the License, or (at your option)
> + * any later version.
> + */
> +
> +#include
> +#include
> +#include "hid-ids.h"
> +
> +static int accutouch_input_mapping(struct hid_device *hdev,
> +struct hid_input *hi,
> +struct hid_field *field,
> +struct hid_usage *usage,
> +unsigned long **bit, int *max)
> +{
> + if ((usage->hid & HID_USAGE_PAGE) == HID_UP_BUTTON) {
> + hid_map_usage(hi, usage, bit, max, EV_KEY, BTN_TOUCH);
> + return 1;
> + }
> +
> + return 0;
> +}
> +
> +static const struct hid_device_id accutouch_devices[] = {
> + { HID_USB_DEVICE(USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_ACCUTOUCH_2216) },
> + { }
> +};
> +MODULE_DEVICE_TABLE(hid, accutouch_devices);
> +
> +static struct hid_driver accutouch_driver = {
> + .name = "hid-accutouch",
> + .id_table = accutouch_devices,
> + .input_mapping = accutouch_input_mapping,
> +};
> +
> +module_hid_driver(accutouch_driver);
> +
> +MODULE_AUTHOR("Martyn Welch +MODULE_DESCRIPTION("Elo Accutouch HID TouchScreen driver");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index ea36b55..b697491 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -1893,6 +1893,7 @@ void hid_disconnect(struct hid_device *hdev)
> { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_ELECOM,
> USB_DEVICE_ID_ELECOM_BM084) },
> { H
Re: [PATCH] HID: Accutouch: Add driver for ELO Accutouch 2216 USB Touchscreens
On Wed, Mar 01, 2017 at 02:30:31PM +0100, Benjamin Tissoires wrote: > Hi, > > On Feb 28 2017 or thereabouts, Martyn Welch wrote: > > This patch has been sitting on the list for about 2 weeks. Is there > > anything wrong with this patch? > > The only wrong thing with the patch (I haven't started reviewing it yet) > is the timing. It was sent shortly before or at the time of the merge > window, where Jiri doesn't want to take new patches in, especially if > they add new drivers. For my side, I wasn't able to do much upstream > work for 3 weeks for personal reasons, urgent stuffs at work and time > off. I'll try to review it today or tomorrow, but don't expect Jiri to > take it until the merge window is closed (this Sunday normally, but you > should probably give him some time to process all the backlog from those > past 3 weeks). > Thanks for the info Benjamin, much appreciated. Martyn > Cheers, > Benjamin > > > > > Thanks, > > > > Martyn > > > > On Tue, Feb 14, 2017 at 02:17:56PM +, Martyn Welch wrote: > > > The Accutouch 2216 is reporting BTN_LEFT/BTN_MOUSE rather than BTM_TOUCH > > > in it's capabilities, which is what user space expects a touchscreen > > > device to report. This is causing udev to consider the device to be a > > > "VMware's USB mouse" rather than as a touchscreen, which results in a > > > mouse cursor being displayed in Weston. > > > > > > This patch adds a special driver for the device to correct the > > > capabilities reported. > > > > > > Signed-off-by: Martyn Welch > > > --- > > > drivers/hid/Kconfig | 12 +++ > > > drivers/hid/Makefile| 1 + > > > drivers/hid/hid-accutouch.c | 52 > > > + > > > drivers/hid/hid-core.c | 1 + > > > drivers/hid/hid-ids.h | 1 + > > > 5 files changed, 67 insertions(+) > > > create mode 100644 drivers/hid/hid-accutouch.c > > > > > > diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig > > > index 4070b73..ba0d17a 100644 > > > --- a/drivers/hid/Kconfig > > > +++ b/drivers/hid/Kconfig > > > @@ -98,6 +98,18 @@ config HID_A4TECH > > > ---help--- > > > Support for A4 tech X5 and WOP-35 / Trust 450L mice. > > > > > > +config HID_ACCUTOUCH > > > + tristate "Accutouch touch device" > > > + depends on USB_HID > > > + ---help--- > > > + This selects a driver for the Accutouch 2216 touch controller. > > > + > > > + The driver works around a problem in the reported device capabilities > > > + which causes userspace to detect the device as a mouse rather than > > > + a touchscreen. > > > + > > > + Say Y here if you have a Accutouch 2216 touch controller. > > > + > > > config HID_ACRUX > > > tristate "ACRUX game controller support" > > > depends on HID > > > diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile > > > index 4d111f2..48be3ed 100644 > > > --- a/drivers/hid/Makefile > > > +++ b/drivers/hid/Makefile > > > @@ -21,6 +21,7 @@ hid-wiimote-y := hid-wiimote-core.o > > > hid-wiimote-modules.o > > > hid-wiimote-$(CONFIG_DEBUG_FS) += hid-wiimote-debug.o > > > > > > obj-$(CONFIG_HID_A4TECH) += hid-a4tech.o > > > +obj-$(CONFIG_HID_ACCUTOUCH) += hid-accutouch.o > > > obj-$(CONFIG_HID_ALPS) += hid-alps.o > > > obj-$(CONFIG_HID_ACRUX) += hid-axff.o > > > obj-$(CONFIG_HID_APPLE) += hid-apple.o > > > diff --git a/drivers/hid/hid-accutouch.c b/drivers/hid/hid-accutouch.c > > > new file mode 100644 > > > index 000..4e28716 > > > --- /dev/null > > > +++ b/drivers/hid/hid-accutouch.c > > > @@ -0,0 +1,52 @@ > > > +/* > > > + * HID driver for Elo Accutouch touchscreens > > > + * > > > + * Copyright (c) 2016, Collabora Ltd. > > > + * Copyright (c) 2016, General Electric Company > > > + * > > > + * based on hid-penmount.c > > > + * Copyright (c) 2014 Christian Gmeiner > > > gmail.com> > > > + */ > > > + > > > +/* > > > + * This program is free software; you can redistribute it and/or modify > > > it > > > + * under the terms of the GNU General Public License as published by the > > > Free > > &g
[PATCH] HID: Accutouch: Add driver for ELO Accutouch 2216 USB Touchscreens
The Accutouch 2216 is reporting BTN_LEFT/BTN_MOUSE rather than BTM_TOUCH
in it's capabilities, which is what user space expects a touchscreen
device to report. This is causing udev to consider the device to be a
"VMware's USB mouse" rather than as a touchscreen, which results in a
mouse cursor being displayed in Weston.
This patch adds a special driver for the device to correct the
capabilities reported.
Signed-off-by: Martyn Welch
---
drivers/hid/Kconfig | 12 +++
drivers/hid/Makefile| 1 +
drivers/hid/hid-accutouch.c | 52 +
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-ids.h | 1 +
5 files changed, 67 insertions(+)
create mode 100644 drivers/hid/hid-accutouch.c
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 4070b73..ba0d17a 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -98,6 +98,18 @@ config HID_A4TECH
---help---
Support for A4 tech X5 and WOP-35 / Trust 450L mice.
+config HID_ACCUTOUCH
+ tristate "Accutouch touch device"
+ depends on USB_HID
+ ---help---
+ This selects a driver for the Accutouch 2216 touch controller.
+
+ The driver works around a problem in the reported device capabilities
+ which causes userspace to detect the device as a mouse rather than
+ a touchscreen.
+
+ Say Y here if you have a Accutouch 2216 touch controller.
+
config HID_ACRUX
tristate "ACRUX game controller support"
depends on HID
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index 4d111f2..48be3ed 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -21,6 +21,7 @@ hid-wiimote-y := hid-wiimote-core.o
hid-wiimote-modules.o
hid-wiimote-$(CONFIG_DEBUG_FS) += hid-wiimote-debug.o
obj-$(CONFIG_HID_A4TECH) += hid-a4tech.o
+obj-$(CONFIG_HID_ACCUTOUCH)+= hid-accutouch.o
obj-$(CONFIG_HID_ALPS) += hid-alps.o
obj-$(CONFIG_HID_ACRUX)+= hid-axff.o
obj-$(CONFIG_HID_APPLE)+= hid-apple.o
diff --git a/drivers/hid/hid-accutouch.c b/drivers/hid/hid-accutouch.c
new file mode 100644
index 000..4e28716
--- /dev/null
+++ b/drivers/hid/hid-accutouch.c
@@ -0,0 +1,52 @@
+/*
+ * HID driver for Elo Accutouch touchscreens
+ *
+ * Copyright (c) 2016, Collabora Ltd.
+ * Copyright (c) 2016, General Electric Company
+ *
+ * based on hid-penmount.c
+ * Copyright (c) 2014 Christian Gmeiner gmail.com>
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+#include
+#include
+#include "hid-ids.h"
+
+static int accutouch_input_mapping(struct hid_device *hdev,
+ struct hid_input *hi,
+ struct hid_field *field,
+ struct hid_usage *usage,
+ unsigned long **bit, int *max)
+{
+ if ((usage->hid & HID_USAGE_PAGE) == HID_UP_BUTTON) {
+ hid_map_usage(hi, usage, bit, max, EV_KEY, BTN_TOUCH);
+ return 1;
+ }
+
+ return 0;
+}
+
+static const struct hid_device_id accutouch_devices[] = {
+ { HID_USB_DEVICE(USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_ACCUTOUCH_2216) },
+ { }
+};
+MODULE_DEVICE_TABLE(hid, accutouch_devices);
+
+static struct hid_driver accutouch_driver = {
+ .name = "hid-accutouch",
+ .id_table = accutouch_devices,
+ .input_mapping = accutouch_input_mapping,
+};
+
+module_hid_driver(accutouch_driver);
+
+MODULE_AUTHOR("Martyn Welch
Re: [PATCH] vme: Fix wrong pointer utilization in ca91cx42_slave_get
On 10 January 2017 at 10:45, Augusto Mecking Caringi wrote: > In ca91cx42_slave_get function, the value pointed by vme_base pointer is > set through: > > *vme_base = ioread32(bridge->base + CA91CX42_VSI_BS[i]); > > So it must be dereferenced to be used in calculation of pci_base: > > *pci_base = (dma_addr_t)*vme_base + pci_offset; > > This bug was caught thanks to the following gcc warning: > > drivers/vme/bridges/vme_ca91cx42.c: In function ‘ca91cx42_slave_get’: > drivers/vme/bridges/vme_ca91cx42.c:467:14: warning: cast from pointer to > integer of different size [-Wpointer-to-int-cast] > *pci_base = (dma_addr_t)vme_base + pci_offset; > > Signed-off-by: Augusto Mecking Caringi Acked-By: Martyn Welch > --- > drivers/vme/bridges/vme_ca91cx42.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/vme/bridges/vme_ca91cx42.c > b/drivers/vme/bridges/vme_ca91cx42.c > index 6b5ee89..7cc5122 100644 > --- a/drivers/vme/bridges/vme_ca91cx42.c > +++ b/drivers/vme/bridges/vme_ca91cx42.c > @@ -464,7 +464,7 @@ static int ca91cx42_slave_get(struct vme_slave_resource > *image, int *enabled, > vme_bound = ioread32(bridge->base + CA91CX42_VSI_BD[i]); > pci_offset = ioread32(bridge->base + CA91CX42_VSI_TO[i]); > > - *pci_base = (dma_addr_t)vme_base + pci_offset; > + *pci_base = (dma_addr_t)*vme_base + pci_offset; > *size = (unsigned long long)((vme_bound - *vme_base) + granularity); > > *enabled = 0; > -- > 2.7.4 >
[PATCH] vme: Update documentation to match api
The vme_register_driver() api changed in commit 5d6abf379d73 ("staging:
vme: make match() driver specific to improve non-VME64x support") but the
documentation wasn't updated. Update the documentation to match the API.
Signed-off-by: Martyn Welch
---
Documentation/vme_api.txt | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/Documentation/vme_api.txt b/Documentation/vme_api.txt
index 4ca63a6..9000655 100644
--- a/Documentation/vme_api.txt
+++ b/Documentation/vme_api.txt
@@ -8,13 +8,14 @@ As with other subsystems within the Linux kernel, VME device
drivers register
with the VME subsystem, typically called from the devices init routine. This
is
achieved via a call to the following function:
- int vme_register_driver (struct vme_driver *driver);
+ int vme_register_driver (struct vme_driver *driver, unsigned int ndevs);
If driver registration is successful this function returns zero, if an error
occurred a negative error code will be returned.
A pointer to a structure of type 'vme_driver' must be provided to the
-registration function. The structure is as follows:
+registration function. Along with ndevs, which is the number of devices your
+driver is able to support. The structure is as follows:
struct vme_driver {
struct list_head node;
@@ -32,8 +33,8 @@ At the minimum, the '.name', '.match' and '.probe' elements
of this structure
should be correctly set. The '.name' element is a pointer to a string holding
the device driver's name.
-The '.match' function allows controlling the number of devices that need to
-be registered. The match function should return 1 if a device should be
+The '.match' function allows control over which VME devices should be
registered
+with the driver. The match function should return 1 if a device should be
probed and 0 otherwise. This example match function (from vme_user.c) limits
the number of devices probed to one:
--
2.1.4
Re: [PATCHv2 6/9] staging: vme_user: return -EFAULT on __copy_*_user errors
On 25/06/15 13:05, Dmitry Kalinkin wrote: This is why I think this is not a “we broke userspace” situation. The vme_user module is also in the staging tree and (almost) by definition the API shouldn't be considered as stable. Martyn -- Martyn Welch (Lead Software Engineer) | Registered in England and Wales GE Intelligent Platforms | (3828642) at 100 Barbirolli Square T +44(0)1327322748 | Manchester, M2 3AB E martyn.we...@ge.com | VAT:GB 927559189 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] VME bus error handling overhaul
Hi Dmitry, These are looking good to me. You mention error handling in relation to vme_master_mmap, am I right in thinking patch 3 avoids errors being recorded when triggered by an mmap access (so as not to appear as a spurious error on a later access)? I think it would be worth at least logging errors to the kernel log should they be generated and not be handled by a error handler, so someone using mmap gets at least some form of notification that their accesses are resulting on bus errors. What do you think? Martyn On 02/07/15 15:11, Dmitry Kalinkin wrote: This moves tsi148 error handling into VME subsystem so it can be shared with the other bridge driver. Then there is a change to close a fixme on separating errors by address space. And finally a fix for memory leak problem that was introduced with support of mmap's. The next logical step in this direction would be to add error handling support to ca91cx42 and make it unconditional for tsi148. It also makes much sense to add synchronization to error-related list operations (spinlocks, rcu). Dmitry Kalinkin (3): vme: move tsi148 error handling into VME subsystem vme: include address space in error filtering vme: change bus error handling scheme drivers/vme/bridges/vme_ca91cx42.c | 3 +- drivers/vme/bridges/vme_tsi148.c | 170 ++--- drivers/vme/vme.c | 83 ++ drivers/vme/vme_bridge.h | 21 +++-- 4 files changed, 147 insertions(+), 130 deletions(-) -- Martyn Welch (Lead Software Engineer) | Registered in England and Wales GE Intelligent Platforms | (3828642) at 100 Barbirolli Square T +44(0)1327322748 | Manchester, M2 3AB E martyn.we...@ge.com | VAT:GB 927559189 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 6/9] staging: vme_user: switch to returning -EFAULT on __copy_*_user errors
On 26/06/15 21:39, Dmitry Kalinkin wrote:
Signed-off-by: Dmitry Kalinkin
---
drivers/staging/vme/devices/vme_user.c | 47 --
1 file changed, 11 insertions(+), 36 deletions(-)
diff --git a/drivers/staging/vme/devices/vme_user.c
b/drivers/staging/vme/devices/vme_user.c
index a2345db..ef876a4 100644
--- a/drivers/staging/vme/devices/vme_user.c
+++ b/drivers/staging/vme/devices/vme_user.c
@@ -123,7 +123,6 @@ struct vme_user_vma_priv {
static ssize_t resource_to_user(int minor, char __user *buf, size_t count,
loff_t *ppos)
{
- ssize_t retval;
ssize_t copied = 0;
if (count > image[minor].size_buf)
@@ -135,13 +134,8 @@ static ssize_t resource_to_user(int minor, char __user
*buf, size_t count,
if (copied < 0)
return (int)copied;
- retval = __copy_to_user(buf, image[minor].kern_buf,
- (unsigned long)copied);
- if (retval != 0) {
- copied = (copied - retval);
- pr_info("User copy failed\n");
- return -EINVAL;
- }
+ if (__copy_to_user(buf, image[minor].kern_buf, (unsigned long)copied))
+ return -EFAULT;
return copied;
Does __copy_to_user() not return the number of bytes still to be copied?
The above seems to add the assumption that __copy_to_user()
can't return part way through a copy.
}
@@ -149,21 +143,16 @@ static ssize_t resource_to_user(int minor, char __user
*buf, size_t count,
static ssize_t resource_from_user(unsigned int minor, const char __user *buf,
size_t count, loff_t *ppos)
{
- ssize_t retval;
ssize_t copied = 0;
if (count > image[minor].size_buf)
count = image[minor].size_buf;
- retval = __copy_from_user(image[minor].kern_buf, buf,
- (unsigned long)count);
- if (retval != 0)
- copied = (copied - retval);
- else
- copied = count;
+ if (__copy_from_user(image[minor].kern_buf, buf, (unsigned long)count))
+ return -EFAULT;
Same here.
copied = vme_master_write(image[minor].resource, image[minor].kern_buf,
- copied, *ppos);
+ count, *ppos);
return copied;
}
@@ -172,38 +161,24 @@ static ssize_t buffer_to_user(unsigned int minor, char
__user *buf,
size_t count, loff_t *ppos)
{
void *image_ptr;
- ssize_t retval;
image_ptr = image[minor].kern_buf + *ppos;
+ if (__copy_to_user(buf, image_ptr, (unsigned long)count))
+ return -EFAULT;
Ditto.
- retval = __copy_to_user(buf, image_ptr, (unsigned long)count);
- if (retval != 0) {
- retval = (count - retval);
- pr_warn("Partial copy to userspace\n");
- } else
- retval = count;
-
- /* Return number of bytes successfully read */
- return retval;
+ return count;
}
static ssize_t buffer_from_user(unsigned int minor, const char __user *buf,
size_t count, loff_t *ppos)
{
void *image_ptr;
- size_t retval;
image_ptr = image[minor].kern_buf + *ppos;
+ if (__copy_from_user(image_ptr, buf, (unsigned long)count))
+ return -EFAULT;
And here.
- retval = __copy_from_user(image_ptr, buf, (unsigned long)count);
- if (retval != 0) {
- retval = (count - retval);
- pr_warn("Partial copy to userspace\n");
- } else
- retval = count;
-
- /* Return number of bytes successfully read */
- return retval;
+ return count;
}
static ssize_t vme_user_read(struct file *file, char __user *buf, size_t
count,
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
T +44(0)1327322748 | Manchester, M2 3AB
E martyn.we...@ge.com | VAT:GB 927559189
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
