From: "Andreas Färber" <afaerber@suse.de> To: Mark Brown <broonie@kernel.org> Cc: netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, "Jian-Hong Pan" <starnight@g.ncu.edu.tw>, "Jiri Pirko" <jiri@resnulli.us>, "Marcel Holtmann" <marcel@holtmann.org>, "David S . Miller" <davem@davemloft.net>, "Matthias Brugger" <mbrugger@suse.com>, "Janus Piwek" <jpiwek@arroweurope.com>, "Michael Röder" <michael.roeder@avnet.eu>, "Dollar Chen" <dollar.chen@wtmec.com>, "Ken Yu" <ken.yu@rakwireless.com>, "Ben Whitten" <ben.whitten@lairdtech.com>, "Steve deRosier" <derosier@gmail.com>, linux-spi@vger.kernel.org, LoRa_Community_Support@semtech.com, "Hasnain Virk" <Hasnain.Virk@arm.com> Subject: Re: [RFC net-next 15/15] net: lora: Add Semtech SX1301 Date: Tue, 3 Jul 2018 18:40:41 +0200 [thread overview] Message-ID: <3f6289f9-d345-39a7-f0dd-9d5fa7c86e82@suse.de> (raw) In-Reply-To: <20180703153137.GB13744@sirena.org.uk> Am 03.07.2018 um 17:31 schrieb Mark Brown: > On Tue, Jul 03, 2018 at 05:09:38PM +0200, Andreas Färber wrote: >> Am 03.07.2018 um 16:50 schrieb Mark Brown: >>> A register map would work just as well here, we already have plenty of >>> devices that abstract at this level (most obviously the I2C/SPI devices >>> that use it to offer both interfaces with a single core driver). > >> The address and data registers together form a two-byte SPI message! > >> It is transmitted by writing to the CS register. > >> The received data is afterwards available in another register. > > Right, but it seems from the code that the hardware understands that > it's formatting register I/O and not just shifting in and out a byte > stream which is what a SPI controller does. I'd not be surprised to > learn that the register you're calling a chip select register is a > strobe that initiates the transfer (and that this may be some of the > difficulty you're having with handling it in the way the framework > expects), the pattern with writing 1 followed immediately by 0 is a bit > of a flag here. Yeah, the current implementation assumes exactly that. :) > I've seen such before hardware where I know it was intentionally > designed that way so it wouldn't be totally surprising. If we don't implement a spi_controller here, then IIUC we can't have multiple spi_device implementations for the devices on the receiving end, as they rely on a spi_controller for their APIs. Do you have an alternative solution for abstraction? A regmap would seem to require putting everything into a monolithic SX1301 driver despite those connected chipsets actually being regular, external SPI chips that could also be attached to non-SX1301 SPI masters. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
WARNING: multiple messages have this Message-ID (diff)
From: afaerber@suse.de (Andreas Färber) To: linux-arm-kernel@lists.infradead.org Subject: [RFC net-next 15/15] net: lora: Add Semtech SX1301 Date: Tue, 3 Jul 2018 18:40:41 +0200 [thread overview] Message-ID: <3f6289f9-d345-39a7-f0dd-9d5fa7c86e82@suse.de> (raw) In-Reply-To: <20180703153137.GB13744@sirena.org.uk> Am 03.07.2018 um 17:31 schrieb Mark Brown: > On Tue, Jul 03, 2018 at 05:09:38PM +0200, Andreas F?rber wrote: >> Am 03.07.2018 um 16:50 schrieb Mark Brown: >>> A register map would work just as well here, we already have plenty of >>> devices that abstract at this level (most obviously the I2C/SPI devices >>> that use it to offer both interfaces with a single core driver). > >> The address and data registers together form a two-byte SPI message! > >> It is transmitted by writing to the CS register. > >> The received data is afterwards available in another register. > > Right, but it seems from the code that the hardware understands that > it's formatting register I/O and not just shifting in and out a byte > stream which is what a SPI controller does. I'd not be surprised to > learn that the register you're calling a chip select register is a > strobe that initiates the transfer (and that this may be some of the > difficulty you're having with handling it in the way the framework > expects), the pattern with writing 1 followed immediately by 0 is a bit > of a flag here. Yeah, the current implementation assumes exactly that. :) > I've seen such before hardware where I know it was intentionally > designed that way so it wouldn't be totally surprising. If we don't implement a spi_controller here, then IIUC we can't have multiple spi_device implementations for the devices on the receiving end, as they rely on a spi_controller for their APIs. Do you have an alternative solution for abstraction? A regmap would seem to require putting everything into a monolithic SX1301 driver despite those connected chipsets actually being regular, external SPI chips that could also be attached to non-SX1301 SPI masters. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany GF: Felix Imend?rffer, Jane Smithard, Graham Norton HRB 21284 (AG N?rnberg)
next prev parent reply other threads:[~2018-07-03 16:40 UTC|newest] Thread overview: 173+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-07-01 11:07 [RFC net-next 00/15] net: A socket API for LoRa Andreas Färber 2018-07-01 11:07 ` Andreas Färber 2018-07-01 11:07 ` Andreas Färber 2018-07-01 11:07 ` [RFC net-next 01/15] net: Reserve protocol numbers " Andreas Färber 2018-07-01 11:07 ` Andreas Färber 2018-07-01 11:07 ` Andreas Färber 2018-07-01 11:07 ` [RFC net-next 02/15] net: lora: Define sockaddr_lora Andreas Färber 2018-07-01 11:07 ` Andreas Färber 2018-07-01 11:07 ` Andreas Färber 2018-07-01 11:07 ` [RFC net-next 03/15] net: lora: Add protocol numbers Andreas Färber 2018-07-01 11:07 ` Andreas Färber 2018-07-01 11:07 ` [RFC net-next 04/15] net: Add lora subsystem Andreas Färber 2018-07-01 11:07 ` Andreas Färber 2018-07-01 11:07 ` Andreas Färber 2018-07-01 11:07 ` [RFC net-next 05/15] HACK: net: lora: Deal with .poll_mask in 4.18-rc2 Andreas Färber 2018-07-01 11:07 ` Andreas Färber 2018-07-01 11:07 ` Andreas Färber 2018-07-02 16:22 ` Jiri Pirko 2018-07-02 16:22 ` Jiri Pirko 2018-07-02 16:59 ` Andreas Färber 2018-07-02 16:59 ` Andreas Färber 2018-07-01 11:07 ` [RFC net-next 06/15] net: lora: Prepare for device drivers Andreas Färber 2018-07-01 11:07 ` Andreas Färber 2018-07-01 11:07 ` Andreas Färber 2018-07-01 11:07 ` [RFC net-next 07/15] net: lora: Add Semtech SX1276 Andreas Färber 2018-07-01 11:07 ` Andreas Färber 2018-07-01 12:02 ` Andreas Färber 2018-07-01 12:02 ` Andreas Färber 2018-07-01 11:07 ` [RFC net-next 08/15] net: lora: sx1276: Add debugfs Andreas Färber 2018-07-01 11:07 ` Andreas Färber 2018-07-02 16:26 ` Jiri Pirko 2018-07-02 16:26 ` Jiri Pirko 2018-07-02 17:57 ` Andreas Färber 2018-07-02 17:57 ` Andreas Färber 2018-07-01 11:07 ` [RFC net-next 09/15] net: lora: Prepare EUI helpers Andreas Färber 2018-07-01 11:07 ` Andreas Färber 2018-07-01 11:07 ` [RFC net-next 10/15] net: lora: Add Microchip RN2483 Andreas Färber 2018-07-01 11:07 ` Andreas Färber 2018-07-01 11:08 ` [RFC net-next 11/15] net: lora: Add IMST WiMOD Andreas Färber 2018-07-01 11:08 ` Andreas Färber 2019-01-06 14:57 ` Heinrich Schuchardt 2019-01-06 14:57 ` Heinrich Schuchardt 2019-01-07 11:29 ` Andreas Färber 2019-01-07 11:29 ` Andreas Färber 2018-07-01 11:08 ` [RFC net-next 12/15] net: lora: Add USI WM-SG-SM-42 Andreas Färber 2018-07-01 11:08 ` Andreas Färber 2018-07-01 11:08 ` [RFC net-next 13/15] net: lora: Prepare RAK RAK811 Andreas Färber 2018-07-01 11:08 ` Andreas Färber 2018-07-01 11:08 ` [RFC net-next 14/15] net: lora: Prepare Semtech SX1257 Andreas Färber 2018-07-01 11:08 ` Andreas Färber 2018-07-01 11:08 ` [RFC net-next 15/15] net: lora: Add Semtech SX1301 Andreas Färber 2018-07-01 11:08 ` Andreas Färber 2018-07-02 11:51 ` Ben Whitten 2018-07-02 11:51 ` Ben Whitten 2018-07-03 3:01 ` Andreas Färber 2018-07-03 3:01 ` Andreas Färber 2018-07-05 8:59 ` Ben Whitten 2018-07-05 8:59 ` Ben Whitten 2018-07-05 8:59 ` Ben Whitten 2018-07-02 16:12 ` Mark Brown 2018-07-02 16:12 ` Mark Brown 2018-07-02 16:12 ` Mark Brown 2018-07-02 17:34 ` Andreas Färber 2018-07-02 17:34 ` Andreas Färber 2018-07-02 20:43 ` Ben Whitten 2018-07-02 20:43 ` Ben Whitten 2018-07-03 3:21 ` Andreas Färber 2018-07-03 3:21 ` Andreas Färber 2018-07-03 3:21 ` Andreas Färber 2018-07-05 8:43 ` Ben Whitten 2018-07-05 8:43 ` Ben Whitten 2018-07-05 8:43 ` Ben Whitten 2018-07-03 14:50 ` Mark Brown 2018-07-03 14:50 ` Mark Brown 2018-07-03 15:09 ` Andreas Färber 2018-07-03 15:09 ` Andreas Färber 2018-07-03 15:09 ` Andreas Färber 2018-07-03 15:31 ` Mark Brown 2018-07-03 15:31 ` Mark Brown 2018-07-03 15:31 ` Mark Brown 2018-07-03 16:40 ` Andreas Färber [this message] 2018-07-03 16:40 ` Andreas Färber 2018-07-04 11:43 ` Mark Brown 2018-07-04 11:43 ` Mark Brown 2018-07-04 13:41 ` Ben Whitten 2018-07-04 13:41 ` Ben Whitten 2018-07-04 13:41 ` Ben Whitten 2018-07-04 14:32 ` Mark Brown 2018-07-04 14:32 ` Mark Brown 2018-07-04 14:32 ` Mark Brown 2018-07-03 15:11 ` [RFC net-next 00/15] net: A socket API for LoRa Jian-Hong Pan 2018-07-03 15:11 ` Jian-Hong Pan 2018-07-03 15:11 ` Jian-Hong Pan 2018-08-05 0:11 ` Andreas Färber 2018-08-05 0:11 ` Andreas Färber 2018-08-05 0:11 ` Andreas Färber 2018-08-08 20:36 ` Alan Cox 2018-08-08 20:36 ` Alan Cox 2018-08-08 20:36 ` Alan Cox 2018-08-08 22:42 ` Andreas Färber 2018-08-08 22:42 ` Andreas Färber 2018-08-08 22:42 ` Andreas Färber 2018-08-09 11:59 ` Alan Cox 2018-08-09 11:59 ` Alan Cox 2018-08-09 11:59 ` Alan Cox 2018-08-09 15:02 ` Jian-Hong Pan 2018-08-09 15:02 ` Jian-Hong Pan 2018-08-09 15:02 ` Jian-Hong Pan 2018-08-09 15:21 ` Alexander Aring 2018-08-09 15:21 ` Alexander Aring 2018-08-09 15:21 ` Alexander Aring 2018-08-10 15:57 ` Alan Cox 2018-08-10 15:57 ` Alan Cox 2018-08-10 15:57 ` Alan Cox 2018-08-11 18:30 ` Stefan Schmidt 2018-08-11 18:30 ` Stefan Schmidt 2018-08-11 18:30 ` Stefan Schmidt 2018-08-12 16:49 ` Andreas Färber 2018-08-12 16:49 ` Andreas Färber 2018-08-12 16:49 ` Andreas Färber 2018-08-12 16:37 ` Jian-Hong Pan 2018-08-12 16:37 ` Jian-Hong Pan 2018-08-12 16:37 ` Jian-Hong Pan 2018-08-12 17:59 ` Andreas Färber 2018-08-12 17:59 ` Andreas Färber 2018-08-12 17:59 ` Andreas Färber 2018-08-13 12:36 ` Alan Cox 2018-08-13 12:36 ` Alan Cox 2018-08-13 12:36 ` Alan Cox 2018-08-09 15:12 ` Alexander Aring 2018-08-09 15:12 ` Alexander Aring 2018-08-09 15:12 ` Alexander Aring 2018-08-09 15:12 ` Alexander Aring 2018-08-09 0:50 ` Andreas Färber 2018-08-09 0:50 ` Andreas Färber 2018-08-09 0:50 ` Andreas Färber 2018-07-04 18:26 ` Stefan Schmidt 2018-07-04 18:26 ` Stefan Schmidt 2018-07-04 18:26 ` Stefan Schmidt 2018-07-05 10:43 ` Helmut Tschemernjak 2018-07-05 10:43 ` Helmut Tschemernjak 2018-07-05 10:43 ` Helmut Tschemernjak 2018-07-11 2:07 ` Andreas Färber 2018-07-11 2:07 ` Andreas Färber 2018-07-11 2:07 ` Andreas Färber 2018-07-11 11:45 ` Helmut Tschemernjak 2018-07-11 11:45 ` Helmut Tschemernjak 2018-07-11 11:45 ` Helmut Tschemernjak 2018-07-11 15:21 ` Ben Whitten 2018-07-11 15:21 ` Ben Whitten 2018-07-11 15:21 ` Ben Whitten 2018-07-15 18:13 ` Andreas Färber 2018-07-15 18:13 ` Andreas Färber 2018-07-15 18:13 ` Andreas Färber 2018-07-18 11:28 ` Ben Whitten 2018-07-18 11:28 ` Ben Whitten 2018-07-18 11:28 ` Ben Whitten 2018-07-18 11:28 ` Ben Whitten 2018-08-02 7:52 ` Jian-Hong Pan 2018-08-02 7:52 ` Jian-Hong Pan 2018-08-02 7:52 ` Jian-Hong Pan 2018-08-02 7:52 ` Jian-Hong Pan 2018-08-03 8:44 ` linux-lora.git and LoRaWAN (was: [RFC net-next 00/15] net: A socket API for LoRa) Andreas Färber 2018-08-03 8:44 ` Andreas Färber 2018-08-05 12:49 ` Jian-Hong Pan 2018-08-05 12:49 ` Jian-Hong Pan 2018-08-05 12:49 ` Jian-Hong Pan 2018-08-05 12:49 ` Jian-Hong Pan [not found] ` <20180803150258.791b9942@alans-desktop> 2018-08-05 14:08 ` Jian-Hong Pan 2018-08-05 14:08 ` Jian-Hong Pan 2018-08-05 13:49 ` [RFC net-next 00/15] net: A socket API for LoRa Andreas Färber 2018-08-05 13:49 ` Andreas Färber 2018-08-05 13:49 ` 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=3f6289f9-d345-39a7-f0dd-9d5fa7c86e82@suse.de \ --to=afaerber@suse.de \ --cc=Hasnain.Virk@arm.com \ --cc=LoRa_Community_Support@semtech.com \ --cc=ben.whitten@lairdtech.com \ --cc=broonie@kernel.org \ --cc=davem@davemloft.net \ --cc=derosier@gmail.com \ --cc=dollar.chen@wtmec.com \ --cc=jiri@resnulli.us \ --cc=jpiwek@arroweurope.com \ --cc=ken.yu@rakwireless.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-spi@vger.kernel.org \ --cc=marcel@holtmann.org \ --cc=mbrugger@suse.com \ --cc=michael.roeder@avnet.eu \ --cc=netdev@vger.kernel.org \ --cc=starnight@g.ncu.edu.tw \ /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: linkBe 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.