From: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
To: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Lukasz Czerwinski
<l.czerwinski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] spi: Make core DMA mapping functions generate scatterlists
Date: Wed, 5 Feb 2014 19:13:20 +0100 [thread overview]
Message-ID: <201402051913.20422.marex@denx.de> (raw)
In-Reply-To: <20140205120002.GH22609-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
On Wednesday, February 05, 2014 at 01:00:02 PM, Mark Brown wrote:
> On Wed, Feb 05, 2014 at 07:30:57AM +0100, Marek Vasut wrote:
> > On Sunday, February 02, 2014 at 02:52:52 PM, Mark Brown wrote:
> > > +static int spi_map_buf(struct spi_master *master, struct device *dev,
> > > + struct sg_table *sgt, void *buf, size_t len,
> > > + enum dma_data_direction dir)
> > > +{
> > > + const bool vmalloced_buf = is_vmalloc_addr(buf);
> > > + const int desc_len = vmalloced_buf ? PAGE_SIZE : master->max_dma_len;
> >
> > You might want to rename this to "sg_chunk_max_size" or something,
> > "desc_len" doesn't make much sense here. The variable describes the
> > maximum size of one single scatterlist element.
>
> A scatterlist entry is pretty much an abstract descriptor though. I
> seem to remember looking at the name and thinking it was good that it
> was something less easily applicable to the length of the table but it
> doesn't make much odds.
It's the length of the entry, but I see your point.
> > > + const int sgs = DIV_ROUND_UP(len, desc_len);
> >
> > Looking at this, the variables could generally use a more meaningful
> > name. I think it'd be clearer to call this "num_sg_chunks" or so ?
>
> You do know where I lifted most of these variable names from, right? :P
Yeah, I don't like looking at my old code, it's always so frustrating ;-) Still,
it's a good source for learning how to NOT do things again :)
> Looking at the code again everything seems idiomatic with the naming of
> the fields inside the sg_table - I probably would apply a patch to
> rename but I wouldn't write one.
OK, makes sense.
> > > + min = min_t(size_t, len, desc_len);
> > > +
> > > + if (vmalloced_buf) {
> > > + vm_page = vmalloc_to_page(buf);
> >
> > Just curious, but shouldn't we check if buf != NULL right at the begining
> > of this function?
>
> No need, the check is outside the function along with the check that the
> controller is OK with DMAing on this transfer and so on.
OK, thank you for checking this.
> > > +static void spi_unmap_buf(struct spi_master *master, struct device
> > > *dev, + struct sg_table *sgt, enum dma_data_direction
dir)
> > > +{
> > > + if (sgt->orig_nents) {
> >
> > I don't want to nag, but why not use if (!sgt->...) return; ? This would
> > cut down one level of indent.
>
> I was looking at some stuff which might add a bit more in here if it's
> not just the core doing mappings. Not sure that's sensible though so it
> might never materialise.
OK.
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2014-02-05 18:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-02 13:52 [PATCH] spi: Make core DMA mapping functions generate scatterlists Mark Brown
[not found] ` <1391349172-27668-1-git-send-email-broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2014-02-05 6:30 ` Marek Vasut
2014-02-05 12:00 ` Mark Brown
[not found] ` <20140205120002.GH22609-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2014-02-05 18:13 ` Marek Vasut [this message]
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=201402051913.20422.marex@denx.de \
--to=marex-ynqeqjnshbs@public.gmane.org \
--cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=l.czerwinski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org \
--cc=linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).