Re: [PATCH 1/2] SPI: spi-gpio: store chipselect information in private structure
On 01.08.2012 22:51, Mark Brown wrote: > On Wed, Aug 01, 2012 at 10:45:19PM +0200, Daniel Mack wrote: > >> could you have another look at these patches maybe? They aren't urgent, >> I just want to avoid the get lost. > > Can you please resend them with me in the CCs? My process for handling > patches is very heavily based on my inbox. > Sure. This time, I added you, Grant and Linus W to the patch using Cc: lines. Let's see if that works better :) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 1/2] SPI: spi-gpio: store chipselect information in private structure
On Wed, Aug 01, 2012 at 10:45:19PM +0200, Daniel Mack wrote: > could you have another look at these patches maybe? They aren't urgent, > I just want to avoid the get lost. Can you please resend them with me in the CCs? My process for handling patches is very heavily based on my inbox. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 1/2] SPI: spi-gpio: store chipselect information in private structure
Mark,
could you have another look at these patches maybe? They aren't urgent,
I just want to avoid the get lost.
Thanks for your time,
Daniel
On 25.07.2012 13:44, Daniel Mack wrote:
> The spi-gpio driver currently assumes the chipselect gpio number is
> stored in ->controller_data of the device's static board information.
>
> In devicetree environments, this information is unavailable and has to
> be derived from the DT node.
>
> This patch moves the gpio storage to the controller's private data so
> the DT bindings can easily build upon the driver.
>
> Signed-off-by: Daniel Mack
> ---
> drivers/spi/spi-gpio.c | 34 --
> 1 file changed, 24 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/spi/spi-gpio.c b/drivers/spi/spi-gpio.c
> index 0094c64..e79e311 100644
> --- a/drivers/spi/spi-gpio.c
> +++ b/drivers/spi/spi-gpio.c
> @@ -46,6 +46,7 @@ struct spi_gpio {
> struct spi_bitbang bitbang;
> struct spi_gpio_platform_data pdata;
> struct platform_device *pdev;
> + int cs_gpios[0];
> };
>
> /*--*/
> @@ -89,15 +90,21 @@ struct spi_gpio {
>
> /*--*/
>
> -static inline const struct spi_gpio_platform_data * __pure
> -spi_to_pdata(const struct spi_device *spi)
> +static inline struct spi_gpio * __pure
> +spi_to_spi_gpio(const struct spi_device *spi)
> {
> const struct spi_bitbang*bang;
> - const struct spi_gpio *spi_gpio;
> + struct spi_gpio *spi_gpio;
>
> bang = spi_master_get_devdata(spi->master);
> spi_gpio = container_of(bang, struct spi_gpio, bitbang);
> - return &spi_gpio->pdata;
> + return spi_gpio;
> +}
> +
> +static inline struct spi_gpio_platform_data * __pure
> +spi_to_pdata(const struct spi_device *spi)
> +{
> + return &spi_to_spi_gpio(spi)->pdata;
> }
>
> /* this is #defined to avoid unused-variable warnings when inlining */
> @@ -210,7 +217,8 @@ static u32 spi_gpio_spec_txrx_word_mode3(struct
> spi_device *spi,
>
> static void spi_gpio_chipselect(struct spi_device *spi, int is_active)
> {
> - unsigned long cs = (unsigned long) spi->controller_data;
> + struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
> + unsigned int cs = spi_gpio->cs_gpios[spi->chip_select];
>
> /* set initial clock polarity */
> if (is_active)
> @@ -224,8 +232,9 @@ static void spi_gpio_chipselect(struct spi_device *spi,
> int is_active)
>
> static int spi_gpio_setup(struct spi_device *spi)
> {
> - unsigned long cs = (unsigned long) spi->controller_data;
> - int status = 0;
> + unsigned intcs = (unsigned int) spi->controller_data;
> + int status = 0;
> + struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
>
> if (spi->bits_per_word > 32)
> return -EINVAL;
> @@ -238,8 +247,11 @@ static int spi_gpio_setup(struct spi_device *spi)
> status = gpio_direction_output(cs, spi->mode &
> SPI_CS_HIGH);
> }
> }
> - if (!status)
> + if (!status) {
> status = spi_bitbang_setup(spi);
> + spi_gpio->cs_gpios[spi->chip_select] = cs;
> + }
> +
> if (status) {
> if (!spi->controller_state && cs != SPI_GPIO_NO_CHIPSELECT)
> gpio_free(cs);
> @@ -249,7 +261,8 @@ static int spi_gpio_setup(struct spi_device *spi)
>
> static void spi_gpio_cleanup(struct spi_device *spi)
> {
> - unsigned long cs = (unsigned long) spi->controller_data;
> + struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
> + unsigned int cs = spi_gpio->cs_gpios[spi->chip_select];
>
> if (cs != SPI_GPIO_NO_CHIPSELECT)
> gpio_free(cs);
> @@ -330,7 +343,8 @@ static int __devinit spi_gpio_probe(struct
> platform_device *pdev)
> if (status < 0)
> return status;
>
> - master = spi_alloc_master(&pdev->dev, sizeof *spi_gpio);
> + master = spi_alloc_master(&pdev->dev, sizeof(*spi_gpio) +
> + (sizeof(int) * SPI_N_CHIPSEL));
> if (!master) {
> status = -ENOMEM;
> goto gpio_free;
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 1/2] SPI: spi-gpio: store chipselect information in private structure
On 25.07.2012 22:12, Mark Brown wrote: > On Wed, Jul 25, 2012 at 10:00:18PM +0200, Daniel Mack wrote: > >> I don't know what's wrong here, but clearly, the message in my inbox has > >> To: spi-devel-general@lists.sourceforge.net >> Cc: grant.lik...@secretlab.ca, >> rob.herr...@calxeda.com, >> devicetree-disc...@lists.ozlabs.org, >> Daniel Mack > >> And I sent them off with git "send-email --to >> spi-devel-general@lists.sourceforge.net --cc grant.lik...@secretlab.ca ..." > >> Sorry if that's my mistake, I just don't see it. > > I forwarded <1343216652-1463-1-git-send-email-zon...@gmail.com> to you > under separate cover. > Yes, you're right - I also saw that on the devicetree-discuss archives. Still, I can't see the reason. My MTA's log states: Jul 25 13:44:18 rambrand postfix/smtp[17884]: 84613C0081: to=, relay=127.0.0.1[127.0.0.1]:10024, delay=0.7, delays=0.35/0/0.01/0.34, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as ED410C029D) Jul 25 13:44:19 rambrand postfix/smtp[17898]: ED410C029D: to=, relay=aspmx.l.google.com[173.194.78.26]:25, delay=1.3, delays=0.06/0.19/0.5/0.57, dsn=2.0.0, status=sent (250 2.0.0 OK 1343216659 e19si24125620wec.111) (Each queue ID matches one of the two original patches' Message-ID) As you appearantly received the mail via spi-devel-general, is it possible that that list dropped it? Must be. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 1/2] SPI: spi-gpio: store chipselect information in private structure
On Wed, Jul 25, 2012 at 10:00:18PM +0200, Daniel Mack wrote: > I don't know what's wrong here, but clearly, the message in my inbox has > To: spi-devel-general@lists.sourceforge.net > Cc: grant.lik...@secretlab.ca, > rob.herr...@calxeda.com, > devicetree-disc...@lists.ozlabs.org, > Daniel Mack > And I sent them off with git "send-email --to > spi-devel-general@lists.sourceforge.net --cc grant.lik...@secretlab.ca ..." > Sorry if that's my mistake, I just don't see it. I forwarded <1343216652-1463-1-git-send-email-zon...@gmail.com> to you under separate cover. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 1/2] SPI: spi-gpio: store chipselect information in private structure
On 25.07.2012 21:52, Mark Brown wrote: > On Wed, Jul 25, 2012 at 09:38:58PM +0200, Daniel Mack wrote: >> On 25.07.2012 21:33, Mark Brown wrote: > >>> Always CC maintainers on things... you've not CCed Grant or Linus W, >>> and for now I'm handling SPI patches (though I'm not in MAINTAINERS so >>> missing me is less surprising). > >> I *did* Cc: Grant and all other people that get_maintainer.pl listed. >> For some reason, Grant was dropped from the list on Wolfram's reply, and >> I just did't see that. > > Grant's not in the CCs for the message I replied to which was one of > your patches. I don't know what's wrong here, but clearly, the message in my inbox has To: spi-devel-general@lists.sourceforge.net Cc: grant.lik...@secretlab.ca, rob.herr...@calxeda.com, devicetree-disc...@lists.ozlabs.org, Daniel Mack And I sent them off with git "send-email --to spi-devel-general@lists.sourceforge.net --cc grant.lik...@secretlab.ca ..." Sorry if that's my mistake, I just don't see it. >> Anyway - let's rather discuss about the patchset :) > > Part of the reason I'm being grumpy is I'm not likely to look at it > right now and my workflow is heavily based on things hitting my inbox > (I use a totally different account for generic list mail I'm not CCed on > and it's annoying to move stuff from one to the other). Ok, no hurries. I'm aware that it was a bad time to publish the patches just after the merge window opened. I'll ping you next week. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 1/2] SPI: spi-gpio: store chipselect information in private structure
On Wed, Jul 25, 2012 at 09:38:58PM +0200, Daniel Mack wrote: > On 25.07.2012 21:33, Mark Brown wrote: > > Always CC maintainers on things... you've not CCed Grant or Linus W, > > and for now I'm handling SPI patches (though I'm not in MAINTAINERS so > > missing me is less surprising). > I *did* Cc: Grant and all other people that get_maintainer.pl listed. > For some reason, Grant was dropped from the list on Wolfram's reply, and > I just did't see that. Grant's not in the CCs for the message I replied to which was one of your patches. > Anyway - let's rather discuss about the patchset :) Part of the reason I'm being grumpy is I'm not likely to look at it right now and my workflow is heavily based on things hitting my inbox (I use a totally different account for generic list mail I'm not CCed on and it's annoying to move stuff from one to the other). -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 1/2] SPI: spi-gpio: store chipselect information in private structure
On 25.07.2012 21:33, Mark Brown wrote: > On Wed, Jul 25, 2012 at 01:44:11PM +0200, Daniel Mack wrote: >> The spi-gpio driver currently assumes the chipselect gpio number is >> stored in ->controller_data of the device's static board information. > > Always CC maintainers on things... you've not CCed Grant or Linus W, > and for now I'm handling SPI patches (though I'm not in MAINTAINERS so > missing me is less surprising). I *did* Cc: Grant and all other people that get_maintainer.pl listed. For some reason, Grant was dropped from the list on Wolfram's reply, and I just did't see that. $ scripts/get_maintainer.pl -f drivers/spi/spi-gpio.c (0) [21:35:24] Grant Likely (maintainer:SPI SUBSYSTEM) Rob Herring (maintainer:OPEN FIRMWARE AND...) spi-devel-general@lists.sourceforge.net (open list:SPI SUBSYSTEM) linux-ker...@vger.kernel.org (open list) devicetree-disc...@lists.ozlabs.org (moderated list:OPEN FIRMWARE AND...) And I didn't know about you being in charge for SPI (saw that only today when you sent your pull request to lkml). So, sorry. Anyway - let's rather discuss about the patchset :) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 1/2] SPI: spi-gpio: store chipselect information in private structure
On Wed, Jul 25, 2012 at 01:44:11PM +0200, Daniel Mack wrote: > The spi-gpio driver currently assumes the chipselect gpio number is > stored in ->controller_data of the device's static board information. Always CC maintainers on things... you've not CCed Grant or Linus W, and for now I'm handling SPI patches (though I'm not in MAINTAINERS so missing me is less surprising). -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 1/2] SPI: spi-gpio: store chipselect information in private structure
The spi-gpio driver currently assumes the chipselect gpio number is
stored in ->controller_data of the device's static board information.
In devicetree environments, this information is unavailable and has to
be derived from the DT node.
This patch moves the gpio storage to the controller's private data so
the DT bindings can easily build upon the driver.
Signed-off-by: Daniel Mack
---
drivers/spi/spi-gpio.c | 34 --
1 file changed, 24 insertions(+), 10 deletions(-)
diff --git a/drivers/spi/spi-gpio.c b/drivers/spi/spi-gpio.c
index 0094c64..e79e311 100644
--- a/drivers/spi/spi-gpio.c
+++ b/drivers/spi/spi-gpio.c
@@ -46,6 +46,7 @@ struct spi_gpio {
struct spi_bitbang bitbang;
struct spi_gpio_platform_data pdata;
struct platform_device *pdev;
+ int cs_gpios[0];
};
/*--*/
@@ -89,15 +90,21 @@ struct spi_gpio {
/*--*/
-static inline const struct spi_gpio_platform_data * __pure
-spi_to_pdata(const struct spi_device *spi)
+static inline struct spi_gpio * __pure
+spi_to_spi_gpio(const struct spi_device *spi)
{
const struct spi_bitbang*bang;
- const struct spi_gpio *spi_gpio;
+ struct spi_gpio *spi_gpio;
bang = spi_master_get_devdata(spi->master);
spi_gpio = container_of(bang, struct spi_gpio, bitbang);
- return &spi_gpio->pdata;
+ return spi_gpio;
+}
+
+static inline struct spi_gpio_platform_data * __pure
+spi_to_pdata(const struct spi_device *spi)
+{
+ return &spi_to_spi_gpio(spi)->pdata;
}
/* this is #defined to avoid unused-variable warnings when inlining */
@@ -210,7 +217,8 @@ static u32 spi_gpio_spec_txrx_word_mode3(struct spi_device
*spi,
static void spi_gpio_chipselect(struct spi_device *spi, int is_active)
{
- unsigned long cs = (unsigned long) spi->controller_data;
+ struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
+ unsigned int cs = spi_gpio->cs_gpios[spi->chip_select];
/* set initial clock polarity */
if (is_active)
@@ -224,8 +232,9 @@ static void spi_gpio_chipselect(struct spi_device *spi, int
is_active)
static int spi_gpio_setup(struct spi_device *spi)
{
- unsigned long cs = (unsigned long) spi->controller_data;
- int status = 0;
+ unsigned intcs = (unsigned int) spi->controller_data;
+ int status = 0;
+ struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
if (spi->bits_per_word > 32)
return -EINVAL;
@@ -238,8 +247,11 @@ static int spi_gpio_setup(struct spi_device *spi)
status = gpio_direction_output(cs, spi->mode &
SPI_CS_HIGH);
}
}
- if (!status)
+ if (!status) {
status = spi_bitbang_setup(spi);
+ spi_gpio->cs_gpios[spi->chip_select] = cs;
+ }
+
if (status) {
if (!spi->controller_state && cs != SPI_GPIO_NO_CHIPSELECT)
gpio_free(cs);
@@ -249,7 +261,8 @@ static int spi_gpio_setup(struct spi_device *spi)
static void spi_gpio_cleanup(struct spi_device *spi)
{
- unsigned long cs = (unsigned long) spi->controller_data;
+ struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
+ unsigned int cs = spi_gpio->cs_gpios[spi->chip_select];
if (cs != SPI_GPIO_NO_CHIPSELECT)
gpio_free(cs);
@@ -330,7 +343,8 @@ static int __devinit spi_gpio_probe(struct platform_device
*pdev)
if (status < 0)
return status;
- master = spi_alloc_master(&pdev->dev, sizeof *spi_gpio);
+ master = spi_alloc_master(&pdev->dev, sizeof(*spi_gpio) +
+ (sizeof(int) * SPI_N_CHIPSEL));
if (!master) {
status = -ENOMEM;
goto gpio_free;
--
1.7.10.4
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
