From: David Brownell <david-b@pacbell.net>
To: "Andrea Paterniani" <a.paterniani@swapp-eng.it>
Cc: "Andrew Morton" <akpm@osdl.org>,
"Linux Kernel list" <linux-kernel@vger.kernel.org>
Subject: Re: [patch 2.6.18-git] SPI -- Freescale iMX SPI controller driver
Date: Fri, 6 Oct 2006 16:35:23 -0700 [thread overview]
Message-ID: <200610061635.24216.david-b@pacbell.net> (raw)
In-Reply-To: <FLEPLOLKEPNLMHOILNHPKELOCMAA.a.paterniani@swapp-eng.it>
On Tuesday 03 October 2006 9:08 am, Andrea Paterniani wrote:
> Here some questions and answers to your comments, (please consider I'm nearly new to kernel programming).
>
>
>
> > ...
> > ug. Why not simply open-code
> >
> > readl(addr + DATA);
>
> I found usefull to define macros to use inside code something like
> rd_CONTROL(regs)
> instead of
> readl(regs + 0x08)
> since to me the macro sounds more friendly.
> Should I have to adhere to some standard ?
The standards are more or less to avoid creating namespace clutter,
and to make explicit where register access happens. Defining new
macros violates the former; not being able to tell where the chip
registers are accessed (because they're wrapped in macros) violates
the latter.
> > The use of loops_per_jiffy seems inappropriate. That's an IO-space read in
> > there, which is slow. This timeout will be very long indeed.
>
> Please suggest me what it's more appropriate.
Pick a constant, use it.
> > I see tasklets being scheduled, but no tasklet_disable() or tasklet_kill(),
> > etc. Is this driver racy against shutdown or rmmod?
>
> Do you mean I should use tasklet_kill() inside spi_imx_remove ?
That's how I read it. :)
> > > + drv_data->rd_data_phys = (dma_addr_t)res->start;
> >
> > I don't think it's correct to cast a kernel virtual address straight to a
> > dma_addr_t.
>
> File include/asm-arm/types.h defines
> typedef u32 dma_addr_t;
> Also I think that for ARM architecture resource_size_t in practice
> is u32 since CONFIG_RESOURCES_64BIT isn't defined.
> Is this construction correct ? If not what should I do ?
I think it's correct; it's certainly standard for converting physical
addresses to DMA addresses. (Andrew got that one wrong; resource
addresses are physical, not virtual.)
- Dave
next prev parent reply other threads:[~2006-10-06 23:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-02 15:16 [patch 2.6.18-git] SPI -- Freescale iMX SPI controller driver David Brownell
2006-10-02 17:59 ` Andrew Morton
2006-10-02 20:16 ` David Brownell
2006-10-03 16:08 ` Andrea Paterniani
2006-10-06 23:35 ` David Brownell [this message]
2006-10-07 11:01 ` Andrea Paterniani
2006-10-07 23:50 ` David Brownell
2006-10-02 18:37 ` Thiago Galesi
2006-10-02 20:10 ` David Brownell
2006-10-02 20:38 ` Andrew Morton
2006-10-02 21:09 ` David Brownell
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=200610061635.24216.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=a.paterniani@swapp-eng.it \
--cc=akpm@osdl.org \
--cc=linux-kernel@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.