mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Daniel Ribeiro <drwyrm@gmail.com>
To: David Brownell <david-b@pacbell.net>
Cc: Stefan Schmidt <stefan@datenfreihafen.org>,
	spi-devel-general@lists.sourceforge.net,
	Stefan Schmidt <stefan@openmoko.org>,
	eric.y.miao@gmail.com, linux-kernel@vger.kernel.org,
	sameo@openedhand.com, linux-arm-kernel@lists.arm.linux.org.uk
Subject: Re: [spi-devel-general] [patch 05/14] mfd: PCAP2 driver
Date: Sun, 23 Nov 2008 01:38:57 -0200	[thread overview]
Message-ID: <1227411537.3148.22.camel@brutus> (raw)
In-Reply-To: <200811221819.53186.david-b@pacbell.net>

Em Sáb, 2008-11-22 às 18:19 -0800, David Brownell escreveu:
> SPI-specific bits:
> 
>  - I'd have to see the patch.  The last one I saw still didn't
>    list a SPI_MASTER dependency for the core MFD module.

The next one will.

>  - You should make ezx_pcap_write() and ezx_pcap_read() switch
>    over to spi_write_then_read(), to ensure it's never doing
>    DMA to/from the stack.  I see a byte-order dependency too...

I tried spi_write_then_read before, but it didn't work. I supposed it
was because it was doing 2 transfers as the second transfer rx_buf
always came zeroed. I see that commit
f9b90e39cbc5c4d6ef60022fd1f25d541df0aad1 changed it to do a single
transfer, so i will try it again.

>  - For general paranoia, the probe() should abort if pcap.spi is
>    already set ... and its cleanup path, plus remove(), should
>    null that pointer.

Ok.

>  - If you're going to mark the probe() as __devinit, then mark
>    the remove() as __devexit and use __devexit_p() in the driver
>    struct.

Ok. Shouldn't i use __init instead?

> Other comments about the pcap2 core:

> - Those show_regs/store_regs calls would IMO make more sense
>    in debugfs than in sysfs.

I will just remove those for now.

>  - The set_vreg() stuff would seem to make more sense in a
>    regulator subdevice and driver ... but that's more of a
>    general driver structure thing, and might be fixed later.
> 
>  - Andrew seems to always want a comment explaining why the
>    IRQ handler for I2C and SPI devices needs to queue_work().
>    Maybe the threaded IRQ stuff will help there...
> 
>  - The mask_event()/unmask_event() stuff looks like you're
>    more or less reinventing a baby "struct irq_chip", with
>    register_event() instead of request_irq().

> Re the IRQ stuff, this looks more like what i2c/chips/menelaus.c
> did than mfd/twl4030-irq.c ... in general I think it's better to
> pursue the latter approach, making genirq handle such stuff.
> (Even though it's kind of awkward to use it for I2C or SPI based
> interrupt controllers just now.)

I didn't know i could use genirq with spi. In fact i was using genirq
before, when the driver was using ssp.c. Now, looking at twl4030-irq.c
its clear how i should have done this. Thanks!!

>  - And the ADC sysfs support isn't supporting hwmon models.
>    (Neither does the twl4030 ADC support, but that's not been
>    submitted for mainline yet either...)

I will look into this after i finish the irq stuff.


This is a lot of stuff, thanks for the review. :)

-- 
Daniel Ribeiro


  reply	other threads:[~2008-11-23  3:39 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20081121160403.073751031@dodger.lab.datenfreihafen.org>
2008-11-21 16:04 ` stefan
2008-11-22  5:25   ` [spi-devel-general] " David Brownell
2008-11-22 14:01     ` Eric Miao
2008-11-22 15:54       ` Daniel Ribeiro
2008-11-22 19:08         ` David Brownell
2008-11-22 23:29           ` Stefan Schmidt
2008-11-22 17:12     ` Daniel Ribeiro
2008-11-22 19:19       ` David Brownell
2008-11-22 23:33         ` Stefan Schmidt
2008-11-22 23:58           ` David Brownell
2008-11-23  0:33             ` Stefan Schmidt
2008-11-23  2:19               ` David Brownell
2008-11-23  3:38                 ` Daniel Ribeiro [this message]
2008-11-23  4:59                   ` David Brownell
2008-11-23  7:06                     ` Daniel Ribeiro
2008-11-23  8:26                       ` David Brownell
2008-11-21 16:04 ` [patch 08/14] input: PCAP2 based touchscreen driver stefan
2008-11-21 17:05   ` Dmitry Torokhov
2008-11-22  0:00     ` Stefan Schmidt
2009-04-21  2:18       ` Dmitry Torokhov
2009-04-21  2:38         ` Daniel Ribeiro
2008-11-21 16:04 ` [patch 10/14] LED: PCAP2 based LED driver stefan
2008-11-22 14:08   ` Eric Miao
2008-11-22 15:46     ` Daniel Ribeiro

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=1227411537.3148.22.camel@brutus \
    --to=drwyrm@gmail.com \
    --cc=david-b@pacbell.net \
    --cc=eric.y.miao@gmail.com \
    --cc=linux-arm-kernel@lists.arm.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sameo@openedhand.com \
    --cc=spi-devel-general@lists.sourceforge.net \
    --cc=stefan@datenfreihafen.org \
    --cc=stefan@openmoko.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

all inboxes | Powered by JetHome®