Re: [PATCH v2 1/2] spi: add support for DLN-2 USB-SPI adapter
On Mon, Nov 17, 2014 at 12:53:16PM +0100, Johan Hovold wrote: > On Mon, Nov 17, 2014 at 12:33:01PM +0200, Laurentiu Palcu wrote: > > Hi Johan, > > > > On Fri, Nov 14, 2014 at 11:56:45AM +0100, Johan Havold wrote: > > > On Thu, Nov 13, 2014 at 05:17:21PM +0200, Laurentiu Palcu wrote: > > > > Hi Johan, > > > > > > > > On Thu, Nov 13, 2014 at 01:27:28PM +0100, Johan Havold wrote: > > > > > On Wed, Nov 12, 2014 at 03:38:09PM +0200, Laurentiu Palcu wrote: > > > > And since there's no gain from using the global buffer why not simply > > > use stack allocated ones here as well (e.g. for both tx and rx above)? > > > > However, I will give this a shot though... Sounds reasonable and I could > > probably lose the struct constructs too if the struct contains just > > one field. > > You might want to keep the structs for single-field messages for > consistency reasons (also used in the other dln2 subdrivers). Ok, fair enough. laurentiu -- 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 1/2] spi: add support for DLN-2 USB-SPI adapter
On Mon, Nov 17, 2014 at 12:33:01PM +0200, Laurentiu Palcu wrote:
> Hi Johan,
>
> On Fri, Nov 14, 2014 at 11:56:45AM +0100, Johan Havold wrote:
> > On Thu, Nov 13, 2014 at 05:17:21PM +0200, Laurentiu Palcu wrote:
> > > Hi Johan,
> > >
> > > On Thu, Nov 13, 2014 at 01:27:28PM +0100, Johan Havold wrote:
> > > > On Wed, Nov 12, 2014 at 03:38:09PM +0200, Laurentiu Palcu wrote:
> > I noticed that checkpatch didn't complain, but 81 chars is still >80,
> > right? The newline counts as well (at least in vim).
>
> Isn't it all about visible characters? vim, which I use, does not count
> the newline. I even have a special plugin for linux kernel development
> that highlights the extra characters in red. Also, after looking at
> other files in the kernel, it seems this file is compliant.
You're right. For some reason I had my vim textwidth set to 78. Sorry.
> > > > > +static int dln2_spi_get_cs_num(struct dln2_spi *dln2, u16 *cs_num)
> > > > > +{
> > > > > + int ret;
> > > > > + struct {
> > > > > + u8 port;
> > > > > + } tx;
> > > > > + struct {
> > > > > + __le16 cs_count;
> > > > > + } *rx = dln2->buf;
> > > >
> > > > I don't think you want to use dln2->buf for all these small transfers.
> > > > And what would be protecting it from concurrent use?
> > > >
> > > > Check this throughout.
> > >
> > > I answered this above.
> >
> > So did I. Even though the transfer functions are serialised by spi-core
> > it's not obvious that all your helpers will be.
>
> I really looked this through and I couldn't find an example when one or
> more helpers can be called in parallel. Most of the helpers are called
> from the probe function and the rest are called from
> dln2_spi_transfer_setup(), via dln2_spi_transfer_one_message(). The
> dln2_spi_prepare_message() is called from SPI core's
> spi_pump_messages(), just before calling transfer_one_message()... So,
> it's still serial.
>
> If there is a flaw in my logic, feel free to correct me.
I'm not doubting that you got it right. My point is just that it's hard
for someone else to see whether you did (and someone adding a new helper
later on might not be as careful as you).
> > And since there's no gain from using the global buffer why not simply
> > use stack allocated ones here as well (e.g. for both tx and rx above)?
>
> However, I will give this a shot though... Sounds reasonable and I could
> probably lose the struct constructs too if the struct contains just
> one field.
You might want to keep the structs for single-field messages for
consistency reasons (also used in the other dln2 subdrivers).
Johan
--
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 1/2] spi: add support for DLN-2 USB-SPI adapter
Hi Johan,
On Fri, Nov 14, 2014 at 11:56:45AM +0100, Johan Havold wrote:
> On Thu, Nov 13, 2014 at 05:17:21PM +0200, Laurentiu Palcu wrote:
> > Hi Johan,
> >
> > On Thu, Nov 13, 2014 at 01:27:28PM +0100, Johan Havold wrote:
> > > On Wed, Nov 12, 2014 at 03:38:09PM +0200, Laurentiu Palcu wrote:
>
> > > > +struct dln2_spi {
> > > > + struct platform_device *pdev;
> > > > + struct spi_master *master;
> > > > + u8 port;
> > > > +
> > > > + void *buf;
> > >
> > > Add comment on what is protecting this buffer.
> >
> > No need to protect this buffer. First off, AFAICS, once we register the
> > master, a message queue is initialized by the spi core and the entire
> > communication with the SPI module goes through this queue. Secondly,
> > every TX/RX SPI operation with the Diolan is split in 2 parts: command
> > and response. Once we send the command out, the buffer can be safely
> > reused for the response.
>
> I didn't as for a lock, but for you to put a comment there explaining
> why there's no need for one (e.g. buffer used in what functions that are
> serialised by spi core).
ok, I'll add a comment.
>
> > Also, I guess this answers a couple of your comments below too.
>
> Not really. I still think you should use stack allocated buffer for
> short control transfer.
>
> > > > +
> > > > + u8 bpw;
> > > > + u32 speed;
> > > > + u16 mode;
> > > > + u8 cs;
> >> > +};
>
> > > > +/*
> > > > + * Select/unselect multiple CS lines. The selected lines will be
> > > > automatically
> > > > + * toggled LOW/HIGH by the board firmware during transfers, provided
> > > > they're
> > > > + * enabled first.
> > > > + *
> > > > + * Ex: cs_mask = 0x03 -> CS0 & CS1 will be selected and the next WR/RD
> > > > operation
> > >
> > > Seems you have several comments that wrap at >80 columns (81 above).
> >
> > According to the kernel coding style, 80 columns is the limit, unless
> > readability is affected. The line above does not exceed this limit. Also,
> > checkpatch does not complain.
>
> I noticed that checkpatch didn't complain, but 81 chars is still >80,
> right? The newline counts as well (at least in vim).
Isn't it all about visible characters? vim, which I use, does not count
the newline. I even have a special plugin for linux kernel development
that highlights the extra characters in red. Also, after looking at
other files in the kernel, it seems this file is compliant.
>
> > > > + * will toggle the lines LOW/HIGH automatically.
> > > > + */
> > > > +static int dln2_spi_cs_set(struct dln2_spi *dln2, u8 cs_mask)
>
> [...]
>
> > > > +static int dln2_spi_get_cs_num(struct dln2_spi *dln2, u16 *cs_num)
> > > > +{
> > > > + int ret;
> > > > + struct {
> > > > + u8 port;
> > > > + } tx;
> > > > + struct {
> > > > + __le16 cs_count;
> > > > + } *rx = dln2->buf;
> > >
> > > I don't think you want to use dln2->buf for all these small transfers.
> > > And what would be protecting it from concurrent use?
> > >
> > > Check this throughout.
> >
> > I answered this above.
>
> So did I. Even though the transfer functions are serialised by spi-core
> it's not obvious that all your helpers will be.
I really looked this through and I couldn't find an example when one or
more helpers can be called in parallel. Most of the helpers are called
from the probe function and the rest are called from
dln2_spi_transfer_setup(), via dln2_spi_transfer_one_message(). The
dln2_spi_prepare_message() is called from SPI core's
spi_pump_messages(), just before calling transfer_one_message()... So,
it's still serial.
If there is a flaw in my logic, feel free to correct me.
>
> And since there's no gain from using the global buffer why not simply
> use stack allocated ones here as well (e.g. for both tx and rx above)?
However, I will give this a shot though... Sounds reasonable and I could
probably lose the struct constructs too if the struct contains just
one field.
> > > > +
> > > > + return 0;
> > > > +}
>
> > > > +/*
> > > > + * Copy the data to DLN2 buffer and change the alignment to LE,
> > > > requested by
> > > > + * DLN2 module. SPI core makes sure that the data length is a multiple
> > > > of word
> > > > + * size.
> > >
> > > What about buffer alignment?
> >
> > Buffer alignment? Why should the buffer be aligned? Now that you
> > mentioned it, I realized I should've used "byte order" instead of
> > alignment in the comment above...
>
> You can't just simply cast an unaligned buffer to a type that has a
> minimum alignment requirement > 1. That's what the get/put_unaligned
> helpers are for (see Documentation/unaligned-memory-access.txt).
>
> Perhaps the buffer is properly aligned, just making sure you verified
> this (e.g. what's the size of the header?).
>
> And yes, fixing the wording would be nice as well.
>
You've got a good point here. I must've relied on the fact that x86 is
capable
Re: [PATCH v2 1/2] spi: add support for DLN-2 USB-SPI adapter
Hi Johan,
On Fri, Nov 14, 2014 at 11:56:45AM +0100, Johan Havold wrote:
On Thu, Nov 13, 2014 at 05:17:21PM +0200, Laurentiu Palcu wrote:
Hi Johan,
On Thu, Nov 13, 2014 at 01:27:28PM +0100, Johan Havold wrote:
On Wed, Nov 12, 2014 at 03:38:09PM +0200, Laurentiu Palcu wrote:
+struct dln2_spi {
+ struct platform_device *pdev;
+ struct spi_master *master;
+ u8 port;
+
+ void *buf;
Add comment on what is protecting this buffer.
No need to protect this buffer. First off, AFAICS, once we register the
master, a message queue is initialized by the spi core and the entire
communication with the SPI module goes through this queue. Secondly,
every TX/RX SPI operation with the Diolan is split in 2 parts: command
and response. Once we send the command out, the buffer can be safely
reused for the response.
I didn't as for a lock, but for you to put a comment there explaining
why there's no need for one (e.g. buffer used in what functions that are
serialised by spi core).
ok, I'll add a comment.
Also, I guess this answers a couple of your comments below too.
Not really. I still think you should use stack allocated buffer for
short control transfer.
+
+ u8 bpw;
+ u32 speed;
+ u16 mode;
+ u8 cs;
+};
+/*
+ * Select/unselect multiple CS lines. The selected lines will be
automatically
+ * toggled LOW/HIGH by the board firmware during transfers, provided
they're
+ * enabled first.
+ *
+ * Ex: cs_mask = 0x03 - CS0 CS1 will be selected and the next WR/RD
operation
Seems you have several comments that wrap at 80 columns (81 above).
According to the kernel coding style, 80 columns is the limit, unless
readability is affected. The line above does not exceed this limit. Also,
checkpatch does not complain.
I noticed that checkpatch didn't complain, but 81 chars is still 80,
right? The newline counts as well (at least in vim).
Isn't it all about visible characters? vim, which I use, does not count
the newline. I even have a special plugin for linux kernel development
that highlights the extra characters in red. Also, after looking at
other files in the kernel, it seems this file is compliant.
+ * will toggle the lines LOW/HIGH automatically.
+ */
+static int dln2_spi_cs_set(struct dln2_spi *dln2, u8 cs_mask)
[...]
+static int dln2_spi_get_cs_num(struct dln2_spi *dln2, u16 *cs_num)
+{
+ int ret;
+ struct {
+ u8 port;
+ } tx;
+ struct {
+ __le16 cs_count;
+ } *rx = dln2-buf;
I don't think you want to use dln2-buf for all these small transfers.
And what would be protecting it from concurrent use?
Check this throughout.
I answered this above.
So did I. Even though the transfer functions are serialised by spi-core
it's not obvious that all your helpers will be.
I really looked this through and I couldn't find an example when one or
more helpers can be called in parallel. Most of the helpers are called
from the probe function and the rest are called from
dln2_spi_transfer_setup(), via dln2_spi_transfer_one_message(). The
dln2_spi_prepare_message() is called from SPI core's
spi_pump_messages(), just before calling transfer_one_message()... So,
it's still serial.
If there is a flaw in my logic, feel free to correct me.
And since there's no gain from using the global buffer why not simply
use stack allocated ones here as well (e.g. for both tx and rx above)?
However, I will give this a shot though... Sounds reasonable and I could
probably lose the struct constructs too if the struct contains just
one field.
+
+ return 0;
+}
+/*
+ * Copy the data to DLN2 buffer and change the alignment to LE,
requested by
+ * DLN2 module. SPI core makes sure that the data length is a multiple
of word
+ * size.
What about buffer alignment?
Buffer alignment? Why should the buffer be aligned? Now that you
mentioned it, I realized I should've used byte order instead of
alignment in the comment above...
You can't just simply cast an unaligned buffer to a type that has a
minimum alignment requirement 1. That's what the get/put_unaligned
helpers are for (see Documentation/unaligned-memory-access.txt).
Perhaps the buffer is properly aligned, just making sure you verified
this (e.g. what's the size of the header?).
And yes, fixing the wording would be nice as well.
You've got a good point here. I must've relied on the fact that x86 is
capable of dealing with unaligned access and didn't give it much thought
for other architectures... :/ Well, now that you raised the flag (thank
you for that), I checked the alignment for dln2 tx/rx buffer and appear
to be 4 byte aligned: for tx, the header is 4 bytes; for rx, it's 12
bytes (I'm
Re: [PATCH v2 1/2] spi: add support for DLN-2 USB-SPI adapter
On Mon, Nov 17, 2014 at 12:33:01PM +0200, Laurentiu Palcu wrote:
Hi Johan,
On Fri, Nov 14, 2014 at 11:56:45AM +0100, Johan Havold wrote:
On Thu, Nov 13, 2014 at 05:17:21PM +0200, Laurentiu Palcu wrote:
Hi Johan,
On Thu, Nov 13, 2014 at 01:27:28PM +0100, Johan Havold wrote:
On Wed, Nov 12, 2014 at 03:38:09PM +0200, Laurentiu Palcu wrote:
I noticed that checkpatch didn't complain, but 81 chars is still 80,
right? The newline counts as well (at least in vim).
Isn't it all about visible characters? vim, which I use, does not count
the newline. I even have a special plugin for linux kernel development
that highlights the extra characters in red. Also, after looking at
other files in the kernel, it seems this file is compliant.
You're right. For some reason I had my vim textwidth set to 78. Sorry.
+static int dln2_spi_get_cs_num(struct dln2_spi *dln2, u16 *cs_num)
+{
+ int ret;
+ struct {
+ u8 port;
+ } tx;
+ struct {
+ __le16 cs_count;
+ } *rx = dln2-buf;
I don't think you want to use dln2-buf for all these small transfers.
And what would be protecting it from concurrent use?
Check this throughout.
I answered this above.
So did I. Even though the transfer functions are serialised by spi-core
it's not obvious that all your helpers will be.
I really looked this through and I couldn't find an example when one or
more helpers can be called in parallel. Most of the helpers are called
from the probe function and the rest are called from
dln2_spi_transfer_setup(), via dln2_spi_transfer_one_message(). The
dln2_spi_prepare_message() is called from SPI core's
spi_pump_messages(), just before calling transfer_one_message()... So,
it's still serial.
If there is a flaw in my logic, feel free to correct me.
I'm not doubting that you got it right. My point is just that it's hard
for someone else to see whether you did (and someone adding a new helper
later on might not be as careful as you).
And since there's no gain from using the global buffer why not simply
use stack allocated ones here as well (e.g. for both tx and rx above)?
However, I will give this a shot though... Sounds reasonable and I could
probably lose the struct constructs too if the struct contains just
one field.
You might want to keep the structs for single-field messages for
consistency reasons (also used in the other dln2 subdrivers).
Johan
--
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 1/2] spi: add support for DLN-2 USB-SPI adapter
On Mon, Nov 17, 2014 at 12:53:16PM +0100, Johan Hovold wrote: On Mon, Nov 17, 2014 at 12:33:01PM +0200, Laurentiu Palcu wrote: Hi Johan, On Fri, Nov 14, 2014 at 11:56:45AM +0100, Johan Havold wrote: On Thu, Nov 13, 2014 at 05:17:21PM +0200, Laurentiu Palcu wrote: Hi Johan, On Thu, Nov 13, 2014 at 01:27:28PM +0100, Johan Havold wrote: On Wed, Nov 12, 2014 at 03:38:09PM +0200, Laurentiu Palcu wrote: And since there's no gain from using the global buffer why not simply use stack allocated ones here as well (e.g. for both tx and rx above)? However, I will give this a shot though... Sounds reasonable and I could probably lose the struct constructs too if the struct contains just one field. You might want to keep the structs for single-field messages for consistency reasons (also used in the other dln2 subdrivers). Ok, fair enough. laurentiu -- 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 1/2] spi: add support for DLN-2 USB-SPI adapter
On Thu, Nov 13, 2014 at 01:27:28PM +0100, Johan Havold wrote: > On Wed, Nov 12, 2014 at 03:38:09PM +0200, Laurentiu Palcu wrote: > > This adds support for Diolan DLN2 USB-SPI adapter. > > > > Information about the USB protocol interface can be found in the > > Programmer's Reference Manual [1], see section 5.4.6 for the SPI > > master module commands and responses. John, please delete unneeded context from your replies - it makes it much easier to find any content you've added. signature.asc Description: Digital signature
Re: [PATCH v2 1/2] spi: add support for DLN-2 USB-SPI adapter
On Thu, Nov 13, 2014 at 05:17:21PM +0200, Laurentiu Palcu wrote:
> Hi Johan,
>
> On Thu, Nov 13, 2014 at 01:27:28PM +0100, Johan Havold wrote:
> > On Wed, Nov 12, 2014 at 03:38:09PM +0200, Laurentiu Palcu wrote:
> > > +struct dln2_spi {
> > > + struct platform_device *pdev;
> > > + struct spi_master *master;
> > > + u8 port;
> > > +
> > > + void *buf;
> >
> > Add comment on what is protecting this buffer.
>
> No need to protect this buffer. First off, AFAICS, once we register the
> master, a message queue is initialized by the spi core and the entire
> communication with the SPI module goes through this queue. Secondly,
> every TX/RX SPI operation with the Diolan is split in 2 parts: command
> and response. Once we send the command out, the buffer can be safely
> reused for the response.
I didn't as for a lock, but for you to put a comment there explaining
why there's no need for one (e.g. buffer used in what functions that are
serialised by spi core).
> Also, I guess this answers a couple of your comments below too.
Not really. I still think you should use stack allocated buffer for
short control transfer.
> > > +
> > > + u8 bpw;
> > > + u32 speed;
> > > + u16 mode;
> > > + u8 cs;
>> > +};
> > > +/*
> > > + * Select/unselect multiple CS lines. The selected lines will be
> > > automatically
> > > + * toggled LOW/HIGH by the board firmware during transfers, provided
> > > they're
> > > + * enabled first.
> > > + *
> > > + * Ex: cs_mask = 0x03 -> CS0 & CS1 will be selected and the next WR/RD
> > > operation
> >
> > Seems you have several comments that wrap at >80 columns (81 above).
>
> According to the kernel coding style, 80 columns is the limit, unless
> readability is affected. The line above does not exceed this limit. Also,
> checkpatch does not complain.
I noticed that checkpatch didn't complain, but 81 chars is still >80,
right? The newline counts as well (at least in vim).
> > > + * will toggle the lines LOW/HIGH automatically.
> > > + */
> > > +static int dln2_spi_cs_set(struct dln2_spi *dln2, u8 cs_mask)
[...]
> > > +static int dln2_spi_get_cs_num(struct dln2_spi *dln2, u16 *cs_num)
> > > +{
> > > + int ret;
> > > + struct {
> > > + u8 port;
> > > + } tx;
> > > + struct {
> > > + __le16 cs_count;
> > > + } *rx = dln2->buf;
> >
> > I don't think you want to use dln2->buf for all these small transfers.
> > And what would be protecting it from concurrent use?
> >
> > Check this throughout.
>
> I answered this above.
So did I. Even though the transfer functions are serialised by spi-core
it's not obvious that all your helpers will be.
And since there's no gain from using the global buffer why not simply
use stack allocated ones here as well (e.g. for both tx and rx above)?
> > > + unsigned rx_len = sizeof(*rx);
> > > +
> > > + tx.port = dln2->port;
> > > + ret = dln2_transfer(dln2->pdev, DLN2_SPI_GET_SS_COUNT, , sizeof(tx),
> > > + rx, _len);
> > > + if (ret < 0)
> > > + return ret;
> > > + if (rx_len < sizeof(*rx))
> > > + return -EPROTO;
> > > +
> > > + *cs_num = le16_to_cpu(rx->cs_count);
> > > +
> > > + dev_dbg(>pdev->dev, "cs_num = %d\n", *cs_num);
> >
> > Use the spi device for device messages throughout.
>
> Apparently, I'm consistent with the other SPI master controller drivers.
> All of them use pdev->dev for printing messages. However, I tried it,
> and the prefix is "spi_master (null):" when master->dev is used,
> compared to "dln2-spi dln2-spi.2.auto:" when pdev->dev is used. It looks
> like master->dev.init_name is not set... :/
Ok.
> > > +
> > > + return 0;
> > > +}
> > > +/*
> > > + * Copy the data to DLN2 buffer and change the alignment to LE,
> > > requested by
> > > + * DLN2 module. SPI core makes sure that the data length is a multiple
> > > of word
> > > + * size.
> >
> > What about buffer alignment?
>
> Buffer alignment? Why should the buffer be aligned? Now that you
> mentioned it, I realized I should've used "byte order" instead of
> alignment in the comment above...
You can't just simply cast an unaligned buffer to a type that has a
minimum alignment requirement > 1. That's what the get/put_unaligned
helpers are for (see Documentation/unaligned-memory-access.txt).
Perhaps the buffer is properly aligned, just making sure you verified
this (e.g. what's the size of the header?).
And yes, fixing the wording would be nice as well.
> > > + */
> > > +static int dln2_spi_copy_to_buf(u8 *dln2_buf, const u8 *src, u16 len, u8
> > > bpw)
> > > +{
> > > +#ifdef __LITTLE_ENDIAN
> > > + memcpy(dln2_buf, src, len);
> > > +#else
> > > + if (bpw <= 8)
> > > + memcpy(dln2_buf, src, len);
> >
> > Missing braces.
> ok
>
> >
> > > + else if (bpw <= 16) {
> > > + __le16 *d = (__le16 *) dln2_buf;
> >
> > No spaces after casts.
> ok
>
> >
> > > + u16 *s = (u16 *) src;
> > > +
> > > + len = len / 2;
> > > + while (len--)
> > > + *d++ =
Re: [PATCH v2 1/2] spi: add support for DLN-2 USB-SPI adapter
On Thu, Nov 13, 2014 at 05:17:21PM +0200, Laurentiu Palcu wrote:
Hi Johan,
On Thu, Nov 13, 2014 at 01:27:28PM +0100, Johan Havold wrote:
On Wed, Nov 12, 2014 at 03:38:09PM +0200, Laurentiu Palcu wrote:
+struct dln2_spi {
+ struct platform_device *pdev;
+ struct spi_master *master;
+ u8 port;
+
+ void *buf;
Add comment on what is protecting this buffer.
No need to protect this buffer. First off, AFAICS, once we register the
master, a message queue is initialized by the spi core and the entire
communication with the SPI module goes through this queue. Secondly,
every TX/RX SPI operation with the Diolan is split in 2 parts: command
and response. Once we send the command out, the buffer can be safely
reused for the response.
I didn't as for a lock, but for you to put a comment there explaining
why there's no need for one (e.g. buffer used in what functions that are
serialised by spi core).
Also, I guess this answers a couple of your comments below too.
Not really. I still think you should use stack allocated buffer for
short control transfer.
+
+ u8 bpw;
+ u32 speed;
+ u16 mode;
+ u8 cs;
+};
+/*
+ * Select/unselect multiple CS lines. The selected lines will be
automatically
+ * toggled LOW/HIGH by the board firmware during transfers, provided
they're
+ * enabled first.
+ *
+ * Ex: cs_mask = 0x03 - CS0 CS1 will be selected and the next WR/RD
operation
Seems you have several comments that wrap at 80 columns (81 above).
According to the kernel coding style, 80 columns is the limit, unless
readability is affected. The line above does not exceed this limit. Also,
checkpatch does not complain.
I noticed that checkpatch didn't complain, but 81 chars is still 80,
right? The newline counts as well (at least in vim).
+ * will toggle the lines LOW/HIGH automatically.
+ */
+static int dln2_spi_cs_set(struct dln2_spi *dln2, u8 cs_mask)
[...]
+static int dln2_spi_get_cs_num(struct dln2_spi *dln2, u16 *cs_num)
+{
+ int ret;
+ struct {
+ u8 port;
+ } tx;
+ struct {
+ __le16 cs_count;
+ } *rx = dln2-buf;
I don't think you want to use dln2-buf for all these small transfers.
And what would be protecting it from concurrent use?
Check this throughout.
I answered this above.
So did I. Even though the transfer functions are serialised by spi-core
it's not obvious that all your helpers will be.
And since there's no gain from using the global buffer why not simply
use stack allocated ones here as well (e.g. for both tx and rx above)?
+ unsigned rx_len = sizeof(*rx);
+
+ tx.port = dln2-port;
+ ret = dln2_transfer(dln2-pdev, DLN2_SPI_GET_SS_COUNT, tx, sizeof(tx),
+ rx, rx_len);
+ if (ret 0)
+ return ret;
+ if (rx_len sizeof(*rx))
+ return -EPROTO;
+
+ *cs_num = le16_to_cpu(rx-cs_count);
+
+ dev_dbg(dln2-pdev-dev, cs_num = %d\n, *cs_num);
Use the spi device for device messages throughout.
Apparently, I'm consistent with the other SPI master controller drivers.
All of them use pdev-dev for printing messages. However, I tried it,
and the prefix is spi_master (null): when master-dev is used,
compared to dln2-spi dln2-spi.2.auto: when pdev-dev is used. It looks
like master-dev.init_name is not set... :/
Ok.
+
+ return 0;
+}
+/*
+ * Copy the data to DLN2 buffer and change the alignment to LE,
requested by
+ * DLN2 module. SPI core makes sure that the data length is a multiple
of word
+ * size.
What about buffer alignment?
Buffer alignment? Why should the buffer be aligned? Now that you
mentioned it, I realized I should've used byte order instead of
alignment in the comment above...
You can't just simply cast an unaligned buffer to a type that has a
minimum alignment requirement 1. That's what the get/put_unaligned
helpers are for (see Documentation/unaligned-memory-access.txt).
Perhaps the buffer is properly aligned, just making sure you verified
this (e.g. what's the size of the header?).
And yes, fixing the wording would be nice as well.
+ */
+static int dln2_spi_copy_to_buf(u8 *dln2_buf, const u8 *src, u16 len, u8
bpw)
+{
+#ifdef __LITTLE_ENDIAN
+ memcpy(dln2_buf, src, len);
+#else
+ if (bpw = 8)
+ memcpy(dln2_buf, src, len);
Missing braces.
ok
+ else if (bpw = 16) {
+ __le16 *d = (__le16 *) dln2_buf;
No spaces after casts.
ok
+ u16 *s = (u16 *) src;
+
+ len = len / 2;
+ while (len--)
+ *d++ = cpu_to_le16p(s++);
+ } else {
+ __le32 *d = (__le32 *) dln2_buf;
+ u32 *s = (u32 *) src;
+
+ len = len / 4;
+ while (len--)
+ *d++ = cpu_to_le32p(s++);
+ }
+#endif
+
+ return 0;
+}
[...]
+static int
Re: [PATCH v2 1/2] spi: add support for DLN-2 USB-SPI adapter
On Thu, Nov 13, 2014 at 01:27:28PM +0100, Johan Havold wrote: On Wed, Nov 12, 2014 at 03:38:09PM +0200, Laurentiu Palcu wrote: This adds support for Diolan DLN2 USB-SPI adapter. Information about the USB protocol interface can be found in the Programmer's Reference Manual [1], see section 5.4.6 for the SPI master module commands and responses. John, please delete unneeded context from your replies - it makes it much easier to find any content you've added. signature.asc Description: Digital signature
Re: [PATCH v2 1/2] spi: add support for DLN-2 USB-SPI adapter
Hi Johan, On Thu, Nov 13, 2014 at 01:27:28PM +0100, Johan Havold wrote: > On Wed, Nov 12, 2014 at 03:38:09PM +0200, Laurentiu Palcu wrote: > > This adds support for Diolan DLN2 USB-SPI adapter. > > > > Information about the USB protocol interface can be found in the > > Programmer's Reference Manual [1], see section 5.4.6 for the SPI > > master module commands and responses. > > > > [1] https://www.diolan.com/downloads/dln-api-manual.pdf > > > > Signed-off-by: Laurentiu Palcu > > --- > > drivers/spi/Kconfig| 10 + > > drivers/spi/Makefile | 1 + > > drivers/spi/spi-dln2.c | 793 > > + > > 3 files changed, 804 insertions(+) > > create mode 100644 drivers/spi/spi-dln2.c > > > > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig > > index 62e2242..a52a910 100644 > > --- a/drivers/spi/Kconfig > > +++ b/drivers/spi/Kconfig > > @@ -176,6 +176,16 @@ config SPI_DAVINCI > > help > > SPI master controller for DaVinci/DA8x/OMAP-L/AM1x SPI modules. > > > > +config SPI_DLN2 > > + tristate "Diolan DLN-2 USB SPI adapter" > > + depends on MFD_DLN2 > > + help > > + If you say yes to this option, support will be included for Diolan > > + DLN2, a USB to SPI interface. > > + > > + This driver can also be built as a module. If so, the module > > + will be called spi-dln2. > > + > > config SPI_EFM32 > > tristate "EFM32 SPI controller" > > depends on OF && ARM && (ARCH_EFM32 || COMPILE_TEST) > > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile > > index 762da07..b315da2 100644 > > --- a/drivers/spi/Makefile > > +++ b/drivers/spi/Makefile > > @@ -26,6 +26,7 @@ obj-$(CONFIG_SPI_CADENCE) += spi-cadence.o > > obj-$(CONFIG_SPI_CLPS711X) += spi-clps711x.o > > obj-$(CONFIG_SPI_COLDFIRE_QSPI)+= spi-coldfire-qspi.o > > obj-$(CONFIG_SPI_DAVINCI) += spi-davinci.o > > +obj-$(CONFIG_SPI_DLN2) += spi-dln2.o > > obj-$(CONFIG_SPI_DESIGNWARE) += spi-dw.o > > obj-$(CONFIG_SPI_DW_MMIO) += spi-dw-mmio.o > > obj-$(CONFIG_SPI_DW_PCI) += spi-dw-midpci.o > > diff --git a/drivers/spi/spi-dln2.c b/drivers/spi/spi-dln2.c > > new file mode 100644 > > index 000..8277294 > > --- /dev/null > > +++ b/drivers/spi/spi-dln2.c > > @@ -0,0 +1,793 @@ > > +/* > > + * Driver for the Diolan DLN-2 USB-SPI adapter > > + * > > + * Copyright (c) 2014 Intel Corporation > > + * > > + * 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, version 2. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#define DLN2_SPI_MODULE_ID 0x02 > > +#define DLN2_SPI_CMD(cmd) DLN2_CMD(cmd, DLN2_SPI_MODULE_ID) > > + > > +/* SPI commands */ > > +#define DLN2_SPI_GET_PORT_COUNTDLN2_SPI_CMD(0x00) > > +#define DLN2_SPI_ENABLEDLN2_SPI_CMD(0x11) > > +#define DLN2_SPI_DISABLE DLN2_SPI_CMD(0x12) > > +#define DLN2_SPI_IS_ENABLEDDLN2_SPI_CMD(0x13) > > +#define DLN2_SPI_SET_MODE DLN2_SPI_CMD(0x14) > > +#define DLN2_SPI_GET_MODE DLN2_SPI_CMD(0x15) > > +#define DLN2_SPI_SET_FRAME_SIZEDLN2_SPI_CMD(0x16) > > +#define DLN2_SPI_GET_FRAME_SIZEDLN2_SPI_CMD(0x17) > > +#define DLN2_SPI_SET_FREQUENCY DLN2_SPI_CMD(0x18) > > +#define DLN2_SPI_GET_FREQUENCY DLN2_SPI_CMD(0x19) > > +#define DLN2_SPI_READ_WRITEDLN2_SPI_CMD(0x1A) > > +#define DLN2_SPI_READ DLN2_SPI_CMD(0x1B) > > +#define DLN2_SPI_WRITE DLN2_SPI_CMD(0x1C) > > +#define DLN2_SPI_SET_DELAY_BETWEEN_SS DLN2_SPI_CMD(0x20) > > +#define DLN2_SPI_GET_DELAY_BETWEEN_SS DLN2_SPI_CMD(0x21) > > +#define DLN2_SPI_SET_DELAY_AFTER_SSDLN2_SPI_CMD(0x22) > > +#define DLN2_SPI_GET_DELAY_AFTER_SSDLN2_SPI_CMD(0x23) > > +#define DLN2_SPI_SET_DELAY_BETWEEN_FRAMES DLN2_SPI_CMD(0x24) > > +#define DLN2_SPI_GET_DELAY_BETWEEN_FRAMES DLN2_SPI_CMD(0x25) > > +#define DLN2_SPI_SET_SSDLN2_SPI_CMD(0x26) > > +#define DLN2_SPI_GET_SSDLN2_SPI_CMD(0x27) > > +#define DLN2_SPI_RELEASE_SSDLN2_SPI_CMD(0x28) > > +#define DLN2_SPI_SS_VARIABLE_ENABLEDLN2_SPI_CMD(0x2B) > > +#define DLN2_SPI_SS_VARIABLE_DISABLE DLN2_SPI_CMD(0x2C) > > +#define DLN2_SPI_SS_VARIABLE_IS_ENABLEDDLN2_SPI_CMD(0x2D) > > +#define DLN2_SPI_SS_AAT_ENABLE DLN2_SPI_CMD(0x2E) > > +#define DLN2_SPI_SS_AAT_DISABLEDLN2_SPI_CMD(0x2F) > > +#define DLN2_SPI_SS_AAT_IS_ENABLED DLN2_SPI_CMD(0x30)
Re: [PATCH v2 1/2] spi: add support for DLN-2 USB-SPI adapter
On Wed, Nov 12, 2014 at 03:38:09PM +0200, Laurentiu Palcu wrote: > This adds support for Diolan DLN2 USB-SPI adapter. > > Information about the USB protocol interface can be found in the > Programmer's Reference Manual [1], see section 5.4.6 for the SPI > master module commands and responses. > > [1] https://www.diolan.com/downloads/dln-api-manual.pdf > > Signed-off-by: Laurentiu Palcu > --- > drivers/spi/Kconfig| 10 + > drivers/spi/Makefile | 1 + > drivers/spi/spi-dln2.c | 793 > + > 3 files changed, 804 insertions(+) > create mode 100644 drivers/spi/spi-dln2.c > > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig > index 62e2242..a52a910 100644 > --- a/drivers/spi/Kconfig > +++ b/drivers/spi/Kconfig > @@ -176,6 +176,16 @@ config SPI_DAVINCI > help > SPI master controller for DaVinci/DA8x/OMAP-L/AM1x SPI modules. > > +config SPI_DLN2 > + tristate "Diolan DLN-2 USB SPI adapter" > + depends on MFD_DLN2 > + help > + If you say yes to this option, support will be included for Diolan > + DLN2, a USB to SPI interface. > + > + This driver can also be built as a module. If so, the module > + will be called spi-dln2. > + > config SPI_EFM32 > tristate "EFM32 SPI controller" > depends on OF && ARM && (ARCH_EFM32 || COMPILE_TEST) > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile > index 762da07..b315da2 100644 > --- a/drivers/spi/Makefile > +++ b/drivers/spi/Makefile > @@ -26,6 +26,7 @@ obj-$(CONFIG_SPI_CADENCE) += spi-cadence.o > obj-$(CONFIG_SPI_CLPS711X) += spi-clps711x.o > obj-$(CONFIG_SPI_COLDFIRE_QSPI) += spi-coldfire-qspi.o > obj-$(CONFIG_SPI_DAVINCI)+= spi-davinci.o > +obj-$(CONFIG_SPI_DLN2) += spi-dln2.o > obj-$(CONFIG_SPI_DESIGNWARE) += spi-dw.o > obj-$(CONFIG_SPI_DW_MMIO)+= spi-dw-mmio.o > obj-$(CONFIG_SPI_DW_PCI) += spi-dw-midpci.o > diff --git a/drivers/spi/spi-dln2.c b/drivers/spi/spi-dln2.c > new file mode 100644 > index 000..8277294 > --- /dev/null > +++ b/drivers/spi/spi-dln2.c > @@ -0,0 +1,793 @@ > +/* > + * Driver for the Diolan DLN-2 USB-SPI adapter > + * > + * Copyright (c) 2014 Intel Corporation > + * > + * 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, version 2. > + */ > + > +#include > +#include > +#include > +#include > +#include > + > +#define DLN2_SPI_MODULE_ID 0x02 > +#define DLN2_SPI_CMD(cmd)DLN2_CMD(cmd, DLN2_SPI_MODULE_ID) > + > +/* SPI commands */ > +#define DLN2_SPI_GET_PORT_COUNT DLN2_SPI_CMD(0x00) > +#define DLN2_SPI_ENABLE DLN2_SPI_CMD(0x11) > +#define DLN2_SPI_DISABLE DLN2_SPI_CMD(0x12) > +#define DLN2_SPI_IS_ENABLED DLN2_SPI_CMD(0x13) > +#define DLN2_SPI_SET_MODEDLN2_SPI_CMD(0x14) > +#define DLN2_SPI_GET_MODEDLN2_SPI_CMD(0x15) > +#define DLN2_SPI_SET_FRAME_SIZE DLN2_SPI_CMD(0x16) > +#define DLN2_SPI_GET_FRAME_SIZE DLN2_SPI_CMD(0x17) > +#define DLN2_SPI_SET_FREQUENCY DLN2_SPI_CMD(0x18) > +#define DLN2_SPI_GET_FREQUENCY DLN2_SPI_CMD(0x19) > +#define DLN2_SPI_READ_WRITE DLN2_SPI_CMD(0x1A) > +#define DLN2_SPI_READDLN2_SPI_CMD(0x1B) > +#define DLN2_SPI_WRITE DLN2_SPI_CMD(0x1C) > +#define DLN2_SPI_SET_DELAY_BETWEEN_SSDLN2_SPI_CMD(0x20) > +#define DLN2_SPI_GET_DELAY_BETWEEN_SSDLN2_SPI_CMD(0x21) > +#define DLN2_SPI_SET_DELAY_AFTER_SS DLN2_SPI_CMD(0x22) > +#define DLN2_SPI_GET_DELAY_AFTER_SS DLN2_SPI_CMD(0x23) > +#define DLN2_SPI_SET_DELAY_BETWEEN_FRAMESDLN2_SPI_CMD(0x24) > +#define DLN2_SPI_GET_DELAY_BETWEEN_FRAMESDLN2_SPI_CMD(0x25) > +#define DLN2_SPI_SET_SS DLN2_SPI_CMD(0x26) > +#define DLN2_SPI_GET_SS DLN2_SPI_CMD(0x27) > +#define DLN2_SPI_RELEASE_SS DLN2_SPI_CMD(0x28) > +#define DLN2_SPI_SS_VARIABLE_ENABLE DLN2_SPI_CMD(0x2B) > +#define DLN2_SPI_SS_VARIABLE_DISABLE DLN2_SPI_CMD(0x2C) > +#define DLN2_SPI_SS_VARIABLE_IS_ENABLED DLN2_SPI_CMD(0x2D) > +#define DLN2_SPI_SS_AAT_ENABLE DLN2_SPI_CMD(0x2E) > +#define DLN2_SPI_SS_AAT_DISABLE DLN2_SPI_CMD(0x2F) > +#define DLN2_SPI_SS_AAT_IS_ENABLED DLN2_SPI_CMD(0x30) > +#define DLN2_SPI_SS_BETWEEN_FRAMES_ENABLEDLN2_SPI_CMD(0x31) > +#define DLN2_SPI_SS_BETWEEN_FRAMES_DISABLE DLN2_SPI_CMD(0x32) > +#define DLN2_SPI_SS_BETWEEN_FRAMES_IS_ENABLEDDLN2_SPI_CMD(0x33) > +#define DLN2_SPI_SET_CPHA
Re: [PATCH v2 1/2] spi: add support for DLN-2 USB-SPI adapter
On Wed, Nov 12, 2014 at 03:38:09PM +0200, Laurentiu Palcu wrote: This adds support for Diolan DLN2 USB-SPI adapter. Information about the USB protocol interface can be found in the Programmer's Reference Manual [1], see section 5.4.6 for the SPI master module commands and responses. [1] https://www.diolan.com/downloads/dln-api-manual.pdf Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com --- drivers/spi/Kconfig| 10 + drivers/spi/Makefile | 1 + drivers/spi/spi-dln2.c | 793 + 3 files changed, 804 insertions(+) create mode 100644 drivers/spi/spi-dln2.c diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 62e2242..a52a910 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -176,6 +176,16 @@ config SPI_DAVINCI help SPI master controller for DaVinci/DA8x/OMAP-L/AM1x SPI modules. +config SPI_DLN2 + tristate Diolan DLN-2 USB SPI adapter + depends on MFD_DLN2 + help + If you say yes to this option, support will be included for Diolan + DLN2, a USB to SPI interface. + + This driver can also be built as a module. If so, the module + will be called spi-dln2. + config SPI_EFM32 tristate EFM32 SPI controller depends on OF ARM (ARCH_EFM32 || COMPILE_TEST) diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index 762da07..b315da2 100644 --- a/drivers/spi/Makefile +++ b/drivers/spi/Makefile @@ -26,6 +26,7 @@ obj-$(CONFIG_SPI_CADENCE) += spi-cadence.o obj-$(CONFIG_SPI_CLPS711X) += spi-clps711x.o obj-$(CONFIG_SPI_COLDFIRE_QSPI) += spi-coldfire-qspi.o obj-$(CONFIG_SPI_DAVINCI)+= spi-davinci.o +obj-$(CONFIG_SPI_DLN2) += spi-dln2.o obj-$(CONFIG_SPI_DESIGNWARE) += spi-dw.o obj-$(CONFIG_SPI_DW_MMIO)+= spi-dw-mmio.o obj-$(CONFIG_SPI_DW_PCI) += spi-dw-midpci.o diff --git a/drivers/spi/spi-dln2.c b/drivers/spi/spi-dln2.c new file mode 100644 index 000..8277294 --- /dev/null +++ b/drivers/spi/spi-dln2.c @@ -0,0 +1,793 @@ +/* + * Driver for the Diolan DLN-2 USB-SPI adapter + * + * Copyright (c) 2014 Intel Corporation + * + * 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, version 2. + */ + +#include linux/kernel.h +#include linux/module.h +#include linux/platform_device.h +#include linux/mfd/dln2.h +#include linux/spi/spi.h + +#define DLN2_SPI_MODULE_ID 0x02 +#define DLN2_SPI_CMD(cmd)DLN2_CMD(cmd, DLN2_SPI_MODULE_ID) + +/* SPI commands */ +#define DLN2_SPI_GET_PORT_COUNT DLN2_SPI_CMD(0x00) +#define DLN2_SPI_ENABLE DLN2_SPI_CMD(0x11) +#define DLN2_SPI_DISABLE DLN2_SPI_CMD(0x12) +#define DLN2_SPI_IS_ENABLED DLN2_SPI_CMD(0x13) +#define DLN2_SPI_SET_MODEDLN2_SPI_CMD(0x14) +#define DLN2_SPI_GET_MODEDLN2_SPI_CMD(0x15) +#define DLN2_SPI_SET_FRAME_SIZE DLN2_SPI_CMD(0x16) +#define DLN2_SPI_GET_FRAME_SIZE DLN2_SPI_CMD(0x17) +#define DLN2_SPI_SET_FREQUENCY DLN2_SPI_CMD(0x18) +#define DLN2_SPI_GET_FREQUENCY DLN2_SPI_CMD(0x19) +#define DLN2_SPI_READ_WRITE DLN2_SPI_CMD(0x1A) +#define DLN2_SPI_READDLN2_SPI_CMD(0x1B) +#define DLN2_SPI_WRITE DLN2_SPI_CMD(0x1C) +#define DLN2_SPI_SET_DELAY_BETWEEN_SSDLN2_SPI_CMD(0x20) +#define DLN2_SPI_GET_DELAY_BETWEEN_SSDLN2_SPI_CMD(0x21) +#define DLN2_SPI_SET_DELAY_AFTER_SS DLN2_SPI_CMD(0x22) +#define DLN2_SPI_GET_DELAY_AFTER_SS DLN2_SPI_CMD(0x23) +#define DLN2_SPI_SET_DELAY_BETWEEN_FRAMESDLN2_SPI_CMD(0x24) +#define DLN2_SPI_GET_DELAY_BETWEEN_FRAMESDLN2_SPI_CMD(0x25) +#define DLN2_SPI_SET_SS DLN2_SPI_CMD(0x26) +#define DLN2_SPI_GET_SS DLN2_SPI_CMD(0x27) +#define DLN2_SPI_RELEASE_SS DLN2_SPI_CMD(0x28) +#define DLN2_SPI_SS_VARIABLE_ENABLE DLN2_SPI_CMD(0x2B) +#define DLN2_SPI_SS_VARIABLE_DISABLE DLN2_SPI_CMD(0x2C) +#define DLN2_SPI_SS_VARIABLE_IS_ENABLED DLN2_SPI_CMD(0x2D) +#define DLN2_SPI_SS_AAT_ENABLE DLN2_SPI_CMD(0x2E) +#define DLN2_SPI_SS_AAT_DISABLE DLN2_SPI_CMD(0x2F) +#define DLN2_SPI_SS_AAT_IS_ENABLED DLN2_SPI_CMD(0x30) +#define DLN2_SPI_SS_BETWEEN_FRAMES_ENABLEDLN2_SPI_CMD(0x31) +#define DLN2_SPI_SS_BETWEEN_FRAMES_DISABLE DLN2_SPI_CMD(0x32) +#define DLN2_SPI_SS_BETWEEN_FRAMES_IS_ENABLEDDLN2_SPI_CMD(0x33) +#define DLN2_SPI_SET_CPHA
Re: [PATCH v2 1/2] spi: add support for DLN-2 USB-SPI adapter
Hi Johan, On Thu, Nov 13, 2014 at 01:27:28PM +0100, Johan Havold wrote: On Wed, Nov 12, 2014 at 03:38:09PM +0200, Laurentiu Palcu wrote: This adds support for Diolan DLN2 USB-SPI adapter. Information about the USB protocol interface can be found in the Programmer's Reference Manual [1], see section 5.4.6 for the SPI master module commands and responses. [1] https://www.diolan.com/downloads/dln-api-manual.pdf Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com --- drivers/spi/Kconfig| 10 + drivers/spi/Makefile | 1 + drivers/spi/spi-dln2.c | 793 + 3 files changed, 804 insertions(+) create mode 100644 drivers/spi/spi-dln2.c diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 62e2242..a52a910 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -176,6 +176,16 @@ config SPI_DAVINCI help SPI master controller for DaVinci/DA8x/OMAP-L/AM1x SPI modules. +config SPI_DLN2 + tristate Diolan DLN-2 USB SPI adapter + depends on MFD_DLN2 + help + If you say yes to this option, support will be included for Diolan + DLN2, a USB to SPI interface. + + This driver can also be built as a module. If so, the module + will be called spi-dln2. + config SPI_EFM32 tristate EFM32 SPI controller depends on OF ARM (ARCH_EFM32 || COMPILE_TEST) diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index 762da07..b315da2 100644 --- a/drivers/spi/Makefile +++ b/drivers/spi/Makefile @@ -26,6 +26,7 @@ obj-$(CONFIG_SPI_CADENCE) += spi-cadence.o obj-$(CONFIG_SPI_CLPS711X) += spi-clps711x.o obj-$(CONFIG_SPI_COLDFIRE_QSPI)+= spi-coldfire-qspi.o obj-$(CONFIG_SPI_DAVINCI) += spi-davinci.o +obj-$(CONFIG_SPI_DLN2) += spi-dln2.o obj-$(CONFIG_SPI_DESIGNWARE) += spi-dw.o obj-$(CONFIG_SPI_DW_MMIO) += spi-dw-mmio.o obj-$(CONFIG_SPI_DW_PCI) += spi-dw-midpci.o diff --git a/drivers/spi/spi-dln2.c b/drivers/spi/spi-dln2.c new file mode 100644 index 000..8277294 --- /dev/null +++ b/drivers/spi/spi-dln2.c @@ -0,0 +1,793 @@ +/* + * Driver for the Diolan DLN-2 USB-SPI adapter + * + * Copyright (c) 2014 Intel Corporation + * + * 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, version 2. + */ + +#include linux/kernel.h +#include linux/module.h +#include linux/platform_device.h +#include linux/mfd/dln2.h +#include linux/spi/spi.h + +#define DLN2_SPI_MODULE_ID 0x02 +#define DLN2_SPI_CMD(cmd) DLN2_CMD(cmd, DLN2_SPI_MODULE_ID) + +/* SPI commands */ +#define DLN2_SPI_GET_PORT_COUNTDLN2_SPI_CMD(0x00) +#define DLN2_SPI_ENABLEDLN2_SPI_CMD(0x11) +#define DLN2_SPI_DISABLE DLN2_SPI_CMD(0x12) +#define DLN2_SPI_IS_ENABLEDDLN2_SPI_CMD(0x13) +#define DLN2_SPI_SET_MODE DLN2_SPI_CMD(0x14) +#define DLN2_SPI_GET_MODE DLN2_SPI_CMD(0x15) +#define DLN2_SPI_SET_FRAME_SIZEDLN2_SPI_CMD(0x16) +#define DLN2_SPI_GET_FRAME_SIZEDLN2_SPI_CMD(0x17) +#define DLN2_SPI_SET_FREQUENCY DLN2_SPI_CMD(0x18) +#define DLN2_SPI_GET_FREQUENCY DLN2_SPI_CMD(0x19) +#define DLN2_SPI_READ_WRITEDLN2_SPI_CMD(0x1A) +#define DLN2_SPI_READ DLN2_SPI_CMD(0x1B) +#define DLN2_SPI_WRITE DLN2_SPI_CMD(0x1C) +#define DLN2_SPI_SET_DELAY_BETWEEN_SS DLN2_SPI_CMD(0x20) +#define DLN2_SPI_GET_DELAY_BETWEEN_SS DLN2_SPI_CMD(0x21) +#define DLN2_SPI_SET_DELAY_AFTER_SSDLN2_SPI_CMD(0x22) +#define DLN2_SPI_GET_DELAY_AFTER_SSDLN2_SPI_CMD(0x23) +#define DLN2_SPI_SET_DELAY_BETWEEN_FRAMES DLN2_SPI_CMD(0x24) +#define DLN2_SPI_GET_DELAY_BETWEEN_FRAMES DLN2_SPI_CMD(0x25) +#define DLN2_SPI_SET_SSDLN2_SPI_CMD(0x26) +#define DLN2_SPI_GET_SSDLN2_SPI_CMD(0x27) +#define DLN2_SPI_RELEASE_SSDLN2_SPI_CMD(0x28) +#define DLN2_SPI_SS_VARIABLE_ENABLEDLN2_SPI_CMD(0x2B) +#define DLN2_SPI_SS_VARIABLE_DISABLE DLN2_SPI_CMD(0x2C) +#define DLN2_SPI_SS_VARIABLE_IS_ENABLEDDLN2_SPI_CMD(0x2D) +#define DLN2_SPI_SS_AAT_ENABLE DLN2_SPI_CMD(0x2E) +#define DLN2_SPI_SS_AAT_DISABLEDLN2_SPI_CMD(0x2F) +#define DLN2_SPI_SS_AAT_IS_ENABLED DLN2_SPI_CMD(0x30) +#define DLN2_SPI_SS_BETWEEN_FRAMES_ENABLE DLN2_SPI_CMD(0x31) +#define
