Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-08-18 Thread Wolfram Sang
> unused-but-set-variable by default. How did you enable this warning without > being flooded by the warnings? (I tried W=1) I use W=1. To prevent flooding, I used to replace all -I with -isystem in the Kernel Makefile, but sadly this doesn't work anymore. And I had no time to investigate why.

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-08-18 Thread Wolfram Sang
unused-but-set-variable by default. How did you enable this warning without being flooded by the warnings? (I tried W=1) I use W=1. To prevent flooding, I used to replace all -I with -isystem in the Kernel Makefile, but sadly this doesn't work anymore. And I had no time to investigate why.

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-08-17 Thread York Sun
On 08/15/2015 01:23 PM, Wolfram Sang wrote: > On Tue, Jun 16, 2015 at 10:28:12AM -0700, York Sun wrote: >> Based on i2c-mux-gpio driver, similarly the register based mux >> switch from one bus to another by setting a single register. >> The register can be on PCIe bus, local bus, or any

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-08-17 Thread York Sun
On 08/15/2015 01:23 PM, Wolfram Sang wrote: On Tue, Jun 16, 2015 at 10:28:12AM -0700, York Sun wrote: Based on i2c-mux-gpio driver, similarly the register based mux switch from one bus to another by setting a single register. The register can be on PCIe bus, local bus, or any memory-mapped

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-08-15 Thread Wolfram Sang
On Tue, Jun 16, 2015 at 10:28:12AM -0700, York Sun wrote: > Based on i2c-mux-gpio driver, similarly the register based mux > switch from one bus to another by setting a single register. > The register can be on PCIe bus, local bus, or any memory-mapped > address. > > Signed-off-by: York Sun >

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-08-15 Thread Wolfram Sang
On Tue, Jun 16, 2015 at 10:28:12AM -0700, York Sun wrote: Based on i2c-mux-gpio driver, similarly the register based mux switch from one bus to another by setting a single register. The register can be on PCIe bus, local bus, or any memory-mapped address. Signed-off-by: York Sun

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-06-18 Thread Paul Bolle
On Thu, 2015-06-18 at 11:42 +0200, Alexander Sverdlin wrote: > Most of the usual drivers in the Kernel have this line. Perhaps people copy and paste without really realizing what this macro is supposed to be for. (I didn't know until a few days ago. I needed you to confirm that I figured it out

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-06-18 Thread Alexander Sverdlin
Hi! On 18/06/15 11:32, ext Paul Bolle wrote: > As I understand it, we've established that: > - this macro setups up udev, and modprobe, and friends, to listen to a > "MODALIAS=platform:i2c-mux-reg" message; and > - that there's currently no code in the kernel that will send out this > message. >

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-06-18 Thread Paul Bolle
On Thu, 2015-06-18 at 11:04 +0200, Alexander Sverdlin wrote: > Maybe (and hopefully) there will never be a legacy user of this driver. But > this macro > is perfectly fine, adds no overhead (but modinfo) (The test for any line of code is whether it adds value. Adding no overhead is not adding

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-06-18 Thread Alexander Sverdlin
Hi! On 18/06/15 10:08, ext Paul Bolle wrote: You do not see the platform_device, because there are no users yet, put > > >> > this MODULE_ALIAS() is perfectly fine, it will allow automatic > > >> > module loading > > >> > in non-DT case. >>> > > Do you mean that it will allow

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-06-18 Thread Paul Bolle
Hi Alexander, On Thu, 2015-06-18 at 09:40 +0200, Alexander Sverdlin wrote: > On 17/06/15 18:03, ext Paul Bolle wrote: > >> You do not see the platform_device, because there are no users yet, put > >> > this MODULE_ALIAS() is perfectly fine, it will allow automatic module > >> > loading > >> > in

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-06-18 Thread Alexander Sverdlin
Hello! On 17/06/15 18:43, ext York Sun wrote: >> > Yeah, this is really bad idea. You maybe want something like >> > __iomem "cookie" here instead of this bare pointer. > Let me try. > Could you think about different access widths, please? Not all buses are 32-bits wide and even on 64-bit CPUs

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-06-18 Thread Alexander Sverdlin
Hi! On 17/06/15 18:03, ext Paul Bolle wrote: >> You do not see the platform_device, because there are no users yet, put >> > this MODULE_ALIAS() is perfectly fine, it will allow automatic module >> > loading >> > in non-DT case. > Do you mean that it will allow automatic module loading once the

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-06-18 Thread Paul Bolle
On Thu, 2015-06-18 at 11:42 +0200, Alexander Sverdlin wrote: Most of the usual drivers in the Kernel have this line. Perhaps people copy and paste without really realizing what this macro is supposed to be for. (I didn't know until a few days ago. I needed you to confirm that I figured it out

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-06-18 Thread Alexander Sverdlin
Hi! On 17/06/15 18:03, ext Paul Bolle wrote: You do not see the platform_device, because there are no users yet, put this MODULE_ALIAS() is perfectly fine, it will allow automatic module loading in non-DT case. Do you mean that it will allow automatic module loading once the patch that

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-06-18 Thread Alexander Sverdlin
Hello! On 17/06/15 18:43, ext York Sun wrote: Yeah, this is really bad idea. You maybe want something like __iomem cookie here instead of this bare pointer. Let me try. Could you think about different access widths, please? Not all buses are 32-bits wide and even on 64-bit CPUs one might

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-06-18 Thread Paul Bolle
Hi Alexander, On Thu, 2015-06-18 at 09:40 +0200, Alexander Sverdlin wrote: On 17/06/15 18:03, ext Paul Bolle wrote: You do not see the platform_device, because there are no users yet, put this MODULE_ALIAS() is perfectly fine, it will allow automatic module loading in non-DT case.

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-06-18 Thread Alexander Sverdlin
Hi! On 18/06/15 10:08, ext Paul Bolle wrote: You do not see the platform_device, because there are no users yet, put this MODULE_ALIAS() is perfectly fine, it will allow automatic module loading in non-DT case. Do you mean that it will allow automatic module loading once the

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-06-18 Thread Paul Bolle
On Thu, 2015-06-18 at 11:04 +0200, Alexander Sverdlin wrote: Maybe (and hopefully) there will never be a legacy user of this driver. But this macro is perfectly fine, adds no overhead (but modinfo) (The test for any line of code is whether it adds value. Adding no overhead is not adding

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-06-18 Thread Alexander Sverdlin
Hi! On 18/06/15 11:32, ext Paul Bolle wrote: As I understand it, we've established that: - this macro setups up udev, and modprobe, and friends, to listen to a MODALIAS=platform:i2c-mux-reg message; and - that there's currently no code in the kernel that will send out this message. Did I

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-06-17 Thread York Sun
On 06/17/2015 08:03 AM, Alexander Sverdlin wrote: > Hi! > > On 16/06/15 19:28, ext York Sun wrote: >> Based on i2c-mux-gpio driver, similarly the register based mux >> switch from one bus to another by setting a single register. >> The register can be on PCIe bus, local bus, or any

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-06-17 Thread Paul Bolle
On Wed, 2015-06-17 at 17:00 +0200, Alexander Sverdlin wrote: > You do not see the platform_device, because there are no users yet, put > this MODULE_ALIAS() is perfectly fine, it will allow automatic module loading > in non-DT case. Do you mean that it will allow automatic module loading once the

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-06-17 Thread Alexander Sverdlin
Hi! On 16/06/15 19:28, ext York Sun wrote: > Based on i2c-mux-gpio driver, similarly the register based mux > switch from one bus to another by setting a single register. > The register can be on PCIe bus, local bus, or any memory-mapped > address. > > Signed-off-by: York Sun > CC: Wolfram Sang

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-06-17 Thread Alexander Sverdlin
Hi! On 17/06/15 10:54, ext Paul Bolle wrote: >> +MODULE_ALIAS("platform:i2c-mux-reg"); > As far as I understand it, this alias is only useful if there's a > corresponding struct platform_device, somewhere. Ie, this alias needs a > platform_device that will fire of a

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-06-17 Thread Paul Bolle
A nit and a question follow. On Tue, 2015-06-16 at 10:28 -0700, York Sun wrote: > --- /dev/null > +++ b/drivers/i2c/muxes/i2c-mux-reg.c > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + *

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-06-17 Thread Paul Bolle
A nit and a question follow. On Tue, 2015-06-16 at 10:28 -0700, York Sun wrote: --- /dev/null +++ b/drivers/i2c/muxes/i2c-mux-reg.c + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-06-17 Thread Alexander Sverdlin
Hi! On 16/06/15 19:28, ext York Sun wrote: Based on i2c-mux-gpio driver, similarly the register based mux switch from one bus to another by setting a single register. The register can be on PCIe bus, local bus, or any memory-mapped address. Signed-off-by: York Sun york...@freescale.com

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-06-17 Thread Alexander Sverdlin
Hi! On 17/06/15 10:54, ext Paul Bolle wrote: +MODULE_ALIAS(platform:i2c-mux-reg); As far as I understand it, this alias is only useful if there's a corresponding struct platform_device, somewhere. Ie, this alias needs a platform_device that will fire of a MODALIAS=platform:i2c-mux-reg uevent

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-06-17 Thread York Sun
On 06/17/2015 08:03 AM, Alexander Sverdlin wrote: Hi! On 16/06/15 19:28, ext York Sun wrote: Based on i2c-mux-gpio driver, similarly the register based mux switch from one bus to another by setting a single register. The register can be on PCIe bus, local bus, or any memory-mapped

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-06-17 Thread Paul Bolle
On Wed, 2015-06-17 at 17:00 +0200, Alexander Sverdlin wrote: You do not see the platform_device, because there are no users yet, put this MODULE_ALIAS() is perfectly fine, it will allow automatic module loading in non-DT case. Do you mean that it will allow automatic module loading once the

[PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-06-16 Thread York Sun
Based on i2c-mux-gpio driver, similarly the register based mux switch from one bus to another by setting a single register. The register can be on PCIe bus, local bus, or any memory-mapped address. Signed-off-by: York Sun CC: Wolfram Sang CC: Peter Korsgaard ---

[PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

2015-06-16 Thread York Sun
Based on i2c-mux-gpio driver, similarly the register based mux switch from one bus to another by setting a single register. The register can be on PCIe bus, local bus, or any memory-mapped address. Signed-off-by: York Sun york...@freescale.com CC: Wolfram Sang w...@the-dreams.de CC: Peter