All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Mark Brown <broonie@kernel.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	linux-realtek-soc@lists.infradead.org,
	linux-leds@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-spi <linux-spi@vger.kernel.org>,
	Jacek Anaszewski <jacek.anaszewski@gmail.com>,
	Pavel Machek <pavel@ucw.cz>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Dan Murphy <dmurphy@ti.com>
Subject: Re: [RFC 04/25] spi: gpio: Implement LSB First bitbang support
Date: Thu, 12 Dec 2019 22:08:24 +0100	[thread overview]
Message-ID: <70bf4954-d7ab-e300-017c-c743a40162a4@suse.de> (raw)
In-Reply-To: <20191212171922.GM4310@sirena.org.uk>

Am 12.12.19 um 18:19 schrieb Mark Brown:
> On Thu, Dec 12, 2019 at 04:14:59PM +0100, Andreas Färber wrote:
>> Am 12.12.19 um 09:40 schrieb Geert Uytterhoeven:
>>> On Thu, Dec 12, 2019 at 4:41 AM Andreas Färber <afaerber@suse.de> wrote:
>>>> Add support for slave DT property spi-lsb-first, i.e., SPI_LSB_FIRST mode.
> 
>>>> Duplicate the inline helpers bitbang_txrx_be_cpha{0,1} as LE versions.
>>>> Make checkpatch.pl happy by changing "unsigned" to "unsigned int".
> 
> Separate patch for this?

For the checkpatch cleanup? Or helpers preparation vs. spi-gpio.c usage?

>> So from that angle I don't see a better way than either duplicating the
>> functions or using some macro magic to #include the header twice. If we
>> wanted to go down that path, we could probably de-duplicate the existing
>> two functions, too, but I was trying to err on the cautious side, since
>> I don't have setups to test all four code paths myself (and a ton of
>> more relevant but less fun patches to flush out ;)).
> 
> Yeah, I don't think there's any great options here with the potential
> performance issues - probably the nicest thing would be to autogenerate
> lots of variants but I think that's far more trouble than it's worth.

Maybe add another code comment to revisit that idea later then?

Thanks,
Andreas

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)

WARNING: multiple messages have this Message-ID (diff)
From: "Andreas Färber" <afaerber@suse.de>
To: Mark Brown <broonie@kernel.org>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-realtek-soc@lists.infradead.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-spi <linux-spi@vger.kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Jacek Anaszewski <jacek.anaszewski@gmail.com>,
	Pavel Machek <pavel@ucw.cz>,
	linux-leds@vger.kernel.org, Dan Murphy <dmurphy@ti.com>
Subject: Re: [RFC 04/25] spi: gpio: Implement LSB First bitbang support
Date: Thu, 12 Dec 2019 22:08:24 +0100	[thread overview]
Message-ID: <70bf4954-d7ab-e300-017c-c743a40162a4@suse.de> (raw)
In-Reply-To: <20191212171922.GM4310@sirena.org.uk>

Am 12.12.19 um 18:19 schrieb Mark Brown:
> On Thu, Dec 12, 2019 at 04:14:59PM +0100, Andreas Färber wrote:
>> Am 12.12.19 um 09:40 schrieb Geert Uytterhoeven:
>>> On Thu, Dec 12, 2019 at 4:41 AM Andreas Färber <afaerber@suse.de> wrote:
>>>> Add support for slave DT property spi-lsb-first, i.e., SPI_LSB_FIRST mode.
> 
>>>> Duplicate the inline helpers bitbang_txrx_be_cpha{0,1} as LE versions.
>>>> Make checkpatch.pl happy by changing "unsigned" to "unsigned int".
> 
> Separate patch for this?

For the checkpatch cleanup? Or helpers preparation vs. spi-gpio.c usage?

>> So from that angle I don't see a better way than either duplicating the
>> functions or using some macro magic to #include the header twice. If we
>> wanted to go down that path, we could probably de-duplicate the existing
>> two functions, too, but I was trying to err on the cautious side, since
>> I don't have setups to test all four code paths myself (and a ton of
>> more relevant but less fun patches to flush out ;)).
> 
> Yeah, I don't think there's any great options here with the potential
> performance issues - probably the nicest thing would be to autogenerate
> lots of variants but I think that's far more trouble than it's worth.

Maybe add another code comment to revisit that idea later then?

Thanks,
Andreas

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-12-12 21:08 UTC|newest]

Thread overview: 132+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-12  3:39 [RFC 00/25] arm64: realtek: Add Xnano X5 and implement TM1628/FD628/AiP1618 LED controllers Andreas Färber
2019-12-12  3:39 ` Andreas Färber
2019-12-12  3:39 ` Andreas Färber
2019-12-12  3:39 ` [RFC 01/25] dt-bindings: vendor-prefixes: Add Xnano Andreas Färber
2019-12-12  3:39   ` Andreas Färber
2019-12-19 22:26   ` Rob Herring
2019-12-19 22:26     ` Rob Herring
2019-12-12  3:39 ` [RFC 02/25] dt-bindings: arm: realtek: Add Xnano X5 Andreas Färber
2019-12-12  3:39   ` Andreas Färber
2019-12-19 22:27   ` Rob Herring
2019-12-19 22:27     ` Rob Herring
2019-12-12  3:39 ` [RFC 03/25] arm64: dts: realtek: rtd1295: " Andreas Färber
2019-12-12  3:39   ` Andreas Färber
2019-12-12  3:39 ` [RFC 04/25] spi: gpio: Implement LSB First bitbang support Andreas Färber
2019-12-12  3:39   ` Andreas Färber
2019-12-12  8:40   ` Geert Uytterhoeven
2019-12-12  8:40     ` Geert Uytterhoeven
2019-12-12 15:14     ` Andreas Färber
2019-12-12 15:14       ` Andreas Färber
2019-12-12 17:19       ` Mark Brown
2019-12-12 17:19         ` Mark Brown
2019-12-12 21:08         ` Andreas Färber [this message]
2019-12-12 21:08           ` Andreas Färber
2019-12-13 11:42           ` Mark Brown
2019-12-13 11:42             ` Mark Brown
2019-12-12  3:39 ` [RFC 05/25] dt-bindings: vendor-prefixes: Add Titan Micro Electronics Andreas Färber
2019-12-12  3:39   ` Andreas Färber
2019-12-19 22:31   ` Rob Herring
2019-12-19 22:31     ` Rob Herring
2019-12-12  3:39 ` [RFC 06/25] dt-bindings: leds: Add Titan Micro Electronics TM1628 Andreas Färber
2019-12-12  3:39   ` Andreas Färber
2019-12-19 23:04   ` Rob Herring
2019-12-19 23:04     ` Rob Herring
2019-12-12  3:39 ` [RFC 07/25] " Andreas Färber
2019-12-12  3:39   ` Andreas Färber
2019-12-14  9:48   ` Andreas Färber
2019-12-14  9:48     ` Andreas Färber
2019-12-12  3:39 ` [RFC 08/25] arm64: dts: realtek: rtd129x-zidoo-x9s: Add TM1628 LED controller Andreas Färber
2019-12-12  3:39   ` Andreas Färber
2019-12-12  3:39 ` [RFC 09/25] arm64: dts: realtek: rtd1295-zidoo-x9s: Add regular LEDs to TM1628 Andreas Färber
2019-12-12  3:39   ` Andreas Färber
2019-12-12  3:39 ` [RFC 10/25] dt-bindings: vendor-prefixes: Add Fuda Hisi Microelectronics Andreas Färber
2019-12-12  3:39   ` Andreas Färber
2019-12-19 23:04   ` Rob Herring
2019-12-19 23:04     ` Rob Herring
2019-12-12  3:39 ` [RFC 11/25] dt-bindings: leds: tm1628: Add Fuda Hisi Microelectronics FD628 Andreas Färber
2019-12-12  3:39   ` Andreas Färber
2019-12-19 23:05   ` Rob Herring
2019-12-19 23:05     ` Rob Herring
2019-12-12  3:39 ` [RFC 12/25] " Andreas Färber
2019-12-12  3:39   ` Andreas Färber
2019-12-12  3:39 ` [RFC 13/25] arm64: dts: realtek: rtd1295-xnano-x5: Add FD628 LED controller Andreas Färber
2019-12-12  3:39   ` Andreas Färber
2019-12-12  3:39 ` [RFC 14/25] arm64: dts: realtek: rtd1295-xnano-x5: Add regular LEDs to FD628 Andreas Färber
2019-12-12  3:39   ` Andreas Färber
2019-12-21 20:21   ` Pavel Machek
2019-12-21 20:21     ` Pavel Machek
2019-12-12  3:39 ` [RFC 15/25] dt-bindings: vendor-prefixes: Add Fude Microelectronics Andreas Färber
2019-12-12  3:39   ` Andreas Färber
2019-12-19 23:05   ` Rob Herring
2019-12-19 23:05     ` Rob Herring
2019-12-12  3:39 ` [RFC 16/25] dt-bindings: leds: tm1628: Add Fude Microelectronics AiP1618 Andreas Färber
2019-12-12  3:39   ` Andreas Färber
2019-12-19 23:06   ` Rob Herring
2019-12-19 23:06     ` Rob Herring
2019-12-12  3:39 ` [RFC 17/25] leds: tm1628: Prepare " Andreas Färber
2019-12-12  3:39   ` Andreas Färber
2019-12-21 19:55   ` Andreas Färber
2019-12-21 19:55     ` Andreas Färber
2019-12-12  3:39 ` [RFC 18/25] dt-bindings: leds: tm1628: Define display child nodes Andreas Färber
2019-12-12  3:39   ` Andreas Färber
2019-12-12  3:39 ` [RFC 19/25] leds: tm1628: Add 7-segment display support Andreas Färber
2019-12-12  3:39   ` Andreas Färber
2019-12-12  8:33   ` Geert Uytterhoeven
2019-12-12  8:33     ` Geert Uytterhoeven
2019-12-12 14:10     ` Andreas Färber
2019-12-12 14:10       ` Andreas Färber
2019-12-21 20:23   ` Pavel Machek
2019-12-21 20:23     ` Pavel Machek
2019-12-12  3:39 ` [RFC 20/25] arm64: dts: realtek: rtd1295-zidoo-x9s: Add display to TM1628 Andreas Färber
2019-12-12  3:39   ` Andreas Färber
2019-12-12  3:39 ` [RFC 21/25] arm64: dts: realtek: rtd1295-xnano-x5: Add display to FD628 Andreas Färber
2019-12-12  3:39   ` Andreas Färber
2019-12-12  3:39 ` [RFC 22/25] leds: tm1826: Add combined glyph support Andreas Färber
2019-12-12  3:39   ` Andreas Färber
2019-12-21 20:27   ` Pavel Machek
2019-12-21 20:27     ` Pavel Machek
2019-12-21 20:41     ` Andreas Färber
2019-12-21 20:41       ` Andreas Färber
2019-12-21 21:04       ` Pavel Machek
2019-12-21 21:04         ` Pavel Machek
2019-12-21 21:49         ` Andreas Färber
2019-12-21 21:49           ` Andreas Färber
     [not found]           ` <CANiq72nA9OLa0SjY8W055J_2A32tcp7S98SruKSdWH2dm25VKw@mail.gmail.com>
2019-12-22  3:14             ` Andreas Färber
2019-12-22  3:14               ` Andreas Färber
2020-01-15 14:31               ` Miguel Ojeda
2020-01-15 14:31                 ` Miguel Ojeda
2019-12-12  3:39 ` [RFC 23/25] WIP: leds: tm1628: Prepare TM1628 keys Andreas Färber
2019-12-12  3:39   ` Andreas Färber
2019-12-12  3:39 ` [RFC 24/25] WIP: leds: tm1628: Prepare FD628 keys Andreas Färber
2019-12-12  3:39   ` Andreas Färber
2019-12-12  3:39 ` [RFC 25/25] WIP: leds: tm1628: Prepare AiP1618 keys Andreas Färber
2019-12-12  3:39   ` Andreas Färber
2019-12-12 13:14 ` [RFC 00/25] arm64: realtek: Add Xnano X5 and implement TM1628/FD628/AiP1618 LED controllers Robin Murphy
2019-12-12 13:14   ` Robin Murphy
2019-12-12 13:14   ` Robin Murphy
2019-12-12 20:55   ` Andreas Färber
2019-12-12 20:55     ` Andreas Färber
2019-12-12 20:55     ` Andreas Färber
2019-12-13 14:07     ` Robin Murphy
2019-12-13 14:07       ` Robin Murphy
2019-12-13 14:07       ` Robin Murphy
2019-12-13 14:36       ` Geert Uytterhoeven
2019-12-13 14:36         ` Geert Uytterhoeven
2019-12-13 14:36         ` Geert Uytterhoeven
2020-02-25 21:42       ` Ezra Buehler
2020-02-25 21:42         ` Ezra Buehler
2020-02-25 21:42         ` Ezra Buehler
2020-02-26 13:03         ` Pavel Machek
2020-02-26 13:03           ` Pavel Machek
2020-02-26 13:03           ` Pavel Machek
2020-02-26 13:03           ` Pavel Machek
2019-12-21 18:20 ` Pavel Machek
2019-12-21 18:20   ` Pavel Machek
2019-12-21 18:20   ` Pavel Machek
2019-12-21 21:07   ` Andreas Färber
2019-12-21 21:07     ` Andreas Färber
2019-12-21 21:07     ` Andreas Färber
2020-01-15 13:34 ` Andreas Färber
2020-01-15 13:34   ` Andreas Färber
2020-01-15 13:34   ` Andreas Färber
2020-01-15 13:34   ` Andreas Färber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=70bf4954-d7ab-e300-017c-c743a40162a4@suse.de \
    --to=afaerber@suse.de \
    --cc=broonie@kernel.org \
    --cc=dmurphy@ti.com \
    --cc=geert@linux-m68k.org \
    --cc=jacek.anaszewski@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-realtek-soc@lists.infradead.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.