All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Eddie James <eajames@linux.vnet.ibm.com>
Cc: Eddie James <eajames@linux.ibm.com>,
	linux-spi <linux-spi@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Mark Brown <broonie@kernel.org>, Joel Stanley <joel@jms.id.au>,
	Andrew Jeffery <andrew@aj.id.au>
Subject: Re: [PATCH] spi: Add FSI-attached SPI controller driver
Date: Fri, 7 Feb 2020 21:39:17 +0200	[thread overview]
Message-ID: <CAHp75Vf6HJw=SpK9_HUgcMaaabs5pZEybP4SS-gc1wz5GRcqeg@mail.gmail.com> (raw)
In-Reply-To: <90973143-bd0a-33cf-9eb8-a83be1a9b415@linux.vnet.ibm.com>

On Fri, Feb 7, 2020 at 9:28 PM Eddie James <eajames@linux.vnet.ibm.com> wrote:
> On 2/5/20 9:51 AM, Andy Shevchenko wrote:
> > On Tue, Feb 4, 2020 at 6:06 PM Eddie James <eajames@linux.ibm.com> wrote:
> >> On 2/4/20 5:02 AM, Andy Shevchenko wrote:
> >>> On Mon, Feb 3, 2020 at 10:33 PM Eddie James <eajames@linux.vnet.ibm.com> wrote:
> >>>> On 1/30/20 10:37 AM, Andy Shevchenko wrote:

...

> >>>>>> +       for (i = 0; i < num_bytes; ++i)
> >>>>>> +               rx[i] = (u8)((in >> (8 * ((num_bytes - 1) - i))) & 0xffULL);
> >>>>> Redundant & 0xffULL part.
> >>>>>
> >>>>> Isn't it NIH of get_unalinged_be64 / le64 or something similar?
> >>>> No, these are shift in/out operations. The read register will also have
> >>>> previous operations data in them and must be extracted with only the
> >>>> correct number of bytes.
> >>> Why not to call put_unaligned() how the tail in this case (it's 0 or
> >>> can be easily made to be 0) will affect the result?
> >>
> >> The shift-in is not the same as any byte-swap or unaligned operation.
> >> For however many bytes we've read, we start at that many bytes
> >> left-shifted in the register and copy out to our buffer, moving right
> >> for each next byte... I don't think there is an existing function for
> >> this operation.
> > For me it looks like
> >
> >    u8 tmp[8];
> >
> >    put_unaligned_be64(in, tmp);
> >    memcpy(rx, tmp, num_bytes);
> >
> > put_unaligned*() is just a method to unroll the value to the u8 buffer.
> > See, for example, linux/unaligned/be_byteshift.h implementation.
>
>
> Unforunately it is not the same. put_unaligned_be64 will take the
> highest 8 bits (0xff00000000000000) and move it into tmp[0]. Then
> 0x00ff000000000000 into tmp[1], etc. This is only correct for this
> driver IF my transfer is 8 bytes. If, for example, I transfer 5 bytes,
> then I need 0x000000ff00000000 into tmp[0], 0x00000000ff000000 into
> tmp[1], etc. So I think my current implementation is correct.

Yes, I missed correction of the start address in memcpy(). Otherwise
it's still the same what I was talking about.

> >>>>>> +       return num_bytes;
> >>>>>> +}
> >>>>>> +static int fsi_spi_data_out(u64 *out, const u8 *tx, int len)
> >>>>>> +{
> >>>>> Ditto as for above function. (put_unaligned ...)
> >>> Ditto.
> >>
> >> I don't understand how this could work for transfers of less than 8
> >> bytes, any put_unaligned would access memory that it doesn't own.
> > Ditto.
> >
> >>>>>> +}

-- 
With Best Regards,
Andy Shevchenko

WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Eddie James <eajames-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Cc: Eddie James <eajames-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>,
	linux-spi <linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Linux Kernel Mailing List
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>,
	Andrew Jeffery <andrew-zrmu5oMJ5Fs@public.gmane.org>
Subject: Re: [PATCH] spi: Add FSI-attached SPI controller driver
Date: Fri, 7 Feb 2020 21:39:17 +0200	[thread overview]
Message-ID: <CAHp75Vf6HJw=SpK9_HUgcMaaabs5pZEybP4SS-gc1wz5GRcqeg@mail.gmail.com> (raw)
In-Reply-To: <90973143-bd0a-33cf-9eb8-a83be1a9b415-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>

On Fri, Feb 7, 2020 at 9:28 PM Eddie James <eajames-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> wrote:
> On 2/5/20 9:51 AM, Andy Shevchenko wrote:
> > On Tue, Feb 4, 2020 at 6:06 PM Eddie James <eajames-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org> wrote:
> >> On 2/4/20 5:02 AM, Andy Shevchenko wrote:
> >>> On Mon, Feb 3, 2020 at 10:33 PM Eddie James <eajames-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> wrote:
> >>>> On 1/30/20 10:37 AM, Andy Shevchenko wrote:

...

> >>>>>> +       for (i = 0; i < num_bytes; ++i)
> >>>>>> +               rx[i] = (u8)((in >> (8 * ((num_bytes - 1) - i))) & 0xffULL);
> >>>>> Redundant & 0xffULL part.
> >>>>>
> >>>>> Isn't it NIH of get_unalinged_be64 / le64 or something similar?
> >>>> No, these are shift in/out operations. The read register will also have
> >>>> previous operations data in them and must be extracted with only the
> >>>> correct number of bytes.
> >>> Why not to call put_unaligned() how the tail in this case (it's 0 or
> >>> can be easily made to be 0) will affect the result?
> >>
> >> The shift-in is not the same as any byte-swap or unaligned operation.
> >> For however many bytes we've read, we start at that many bytes
> >> left-shifted in the register and copy out to our buffer, moving right
> >> for each next byte... I don't think there is an existing function for
> >> this operation.
> > For me it looks like
> >
> >    u8 tmp[8];
> >
> >    put_unaligned_be64(in, tmp);
> >    memcpy(rx, tmp, num_bytes);
> >
> > put_unaligned*() is just a method to unroll the value to the u8 buffer.
> > See, for example, linux/unaligned/be_byteshift.h implementation.
>
>
> Unforunately it is not the same. put_unaligned_be64 will take the
> highest 8 bits (0xff00000000000000) and move it into tmp[0]. Then
> 0x00ff000000000000 into tmp[1], etc. This is only correct for this
> driver IF my transfer is 8 bytes. If, for example, I transfer 5 bytes,
> then I need 0x000000ff00000000 into tmp[0], 0x00000000ff000000 into
> tmp[1], etc. So I think my current implementation is correct.

Yes, I missed correction of the start address in memcpy(). Otherwise
it's still the same what I was talking about.

> >>>>>> +       return num_bytes;
> >>>>>> +}
> >>>>>> +static int fsi_spi_data_out(u64 *out, const u8 *tx, int len)
> >>>>>> +{
> >>>>> Ditto as for above function. (put_unaligned ...)
> >>> Ditto.
> >>
> >> I don't understand how this could work for transfers of less than 8
> >> bytes, any put_unaligned would access memory that it doesn't own.
> > Ditto.
> >
> >>>>>> +}

-- 
With Best Regards,
Andy Shevchenko

  reply	other threads:[~2020-02-07 19:39 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-29 20:08 [PATCH] spi: Add FSI-attached SPI controller driver Eddie James
2020-01-29 20:08 ` Eddie James
2020-01-30 14:46 ` Mark Brown
2020-01-30 14:46   ` Mark Brown
2020-01-30 15:32   ` Eddie James
2020-01-30 16:37 ` Andy Shevchenko
2020-01-30 16:37   ` Andy Shevchenko
2020-02-03 20:33   ` Eddie James
2020-02-04 11:02     ` Andy Shevchenko
2020-02-04 11:02       ` Andy Shevchenko
2020-02-04 16:06       ` Eddie James
2020-02-04 16:06         ` Eddie James
2020-02-05 15:51         ` Andy Shevchenko
2020-02-05 15:51           ` Andy Shevchenko
2020-02-07 19:28           ` Eddie James
2020-02-07 19:28             ` Eddie James
2020-02-07 19:39             ` Andy Shevchenko [this message]
2020-02-07 19:39               ` Andy Shevchenko
2020-02-07 20:04               ` Eddie James
2020-02-07 20:04                 ` Eddie James
2020-02-07 20:34                 ` Andy Shevchenko
2020-02-07 20:34                   ` Andy Shevchenko
2020-02-07 20:59                   ` Eddie James
2020-02-07 20:59                     ` Eddie James
2020-02-07 22:04                     ` Andy Shevchenko
2020-02-07 22:04                       ` Andy Shevchenko
2020-02-10 20:05                       ` Eddie James
2020-02-10 20:05                         ` Eddie James
2020-02-10 20:33                         ` Andy Shevchenko
2020-02-10 20:50                           ` Eddie James
2020-02-10 20:50                             ` Eddie James

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='CAHp75Vf6HJw=SpK9_HUgcMaaabs5pZEybP4SS-gc1wz5GRcqeg@mail.gmail.com' \
    --to=andy.shevchenko@gmail.com \
    --cc=andrew@aj.id.au \
    --cc=broonie@kernel.org \
    --cc=eajames@linux.ibm.com \
    --cc=eajames@linux.vnet.ibm.com \
    --cc=joel@jms.id.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    /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.