All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rafal Prylowski <prylowski@metasoft.pl>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel@lists.infradead.org,
	"rmallon@gmail.com" <rmallon@gmail.com>,
	Sergei Shtylyov <sshtylyov@mvista.com>,
	hsweeten@visionengravers.com, linux-ide@vger.kernel.org,
	joao.ramos@inov.pt, bzolnier@gmail.com
Subject: Re: [PATCH 1/3] PATA host controller driver for ep93xx
Date: Mon, 02 Apr 2012 11:28:36 +0200	[thread overview]
Message-ID: <4F797144.400@metasoft.pl> (raw)
In-Reply-To: <201204020808.34529.arnd@arndb.de>

On 2012-04-02 10:08, Arnd Bergmann wrote:
> On Monday 02 April 2012, Rafal Prylowski wrote:
>>
>> I selected "PATA SFF controllers with BMDMA" list because the driver
>> inherits .ata_bmdma_port_ops (this is in libata-sff.c, which is compiled
>> only if ATA_SFF is set).
> 
> Ok, I see. Is it actually the right one to inherit from though?
> 
> You end up overriding most of the opterations that are set there again,
> the only ones that you use are:
> 
> ata_bmdma_error_handler, ata_bmdma_post_internal_cmd, ata_bmdma_qc_issue,
> ata_sff_qc_fill_rtf, ata_sff_freeze, ata_sff_thaw, ata_sff_prereset,
> ata_sff_postreset and ata_sff_error_handler.
> 
> Are you sure they are all doing the righ thing on your hardware? If
> not, it might be better to explicitly just set the ones you need and
> see if that still uses any sff functions in the end.
> 
> 	Arnd

I think that inheriting from .ata_bmdma_port_ops is quite reasonable.
Another option would be to inherit from .ata_sff_port_ops and implement
.qc_issue hook (like in pata_octeon_cf.c), but this way we end up
reimplementing the same things from libata-sff.c, IMHO. Also, I think
that it's not possible to write PATA driver without this SFF stuff
(at least for me - I'm not libata expert).
I reviewed code paths from all hooks used in ep93xx driver to make sure
that we use only ep93xx_pata_read/ep93xx_pata_write instead of ioread/iowrite.

RP

WARNING: multiple messages have this Message-ID (diff)
From: prylowski@metasoft.pl (Rafal Prylowski)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] PATA host controller driver for ep93xx
Date: Mon, 02 Apr 2012 11:28:36 +0200	[thread overview]
Message-ID: <4F797144.400@metasoft.pl> (raw)
In-Reply-To: <201204020808.34529.arnd@arndb.de>

On 2012-04-02 10:08, Arnd Bergmann wrote:
> On Monday 02 April 2012, Rafal Prylowski wrote:
>>
>> I selected "PATA SFF controllers with BMDMA" list because the driver
>> inherits .ata_bmdma_port_ops (this is in libata-sff.c, which is compiled
>> only if ATA_SFF is set).
> 
> Ok, I see. Is it actually the right one to inherit from though?
> 
> You end up overriding most of the opterations that are set there again,
> the only ones that you use are:
> 
> ata_bmdma_error_handler, ata_bmdma_post_internal_cmd, ata_bmdma_qc_issue,
> ata_sff_qc_fill_rtf, ata_sff_freeze, ata_sff_thaw, ata_sff_prereset,
> ata_sff_postreset and ata_sff_error_handler.
> 
> Are you sure they are all doing the righ thing on your hardware? If
> not, it might be better to explicitly just set the ones you need and
> see if that still uses any sff functions in the end.
> 
> 	Arnd

I think that inheriting from .ata_bmdma_port_ops is quite reasonable.
Another option would be to inherit from .ata_sff_port_ops and implement
.qc_issue hook (like in pata_octeon_cf.c), but this way we end up
reimplementing the same things from libata-sff.c, IMHO. Also, I think
that it's not possible to write PATA driver without this SFF stuff
(at least for me - I'm not libata expert).
I reviewed code paths from all hooks used in ep93xx driver to make sure
that we use only ep93xx_pata_read/ep93xx_pata_write instead of ioread/iowrite.

RP

  reply	other threads:[~2012-04-02  9:28 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-29  8:10 [PATCH 0/3] Add PATA host controller support for Cirrus Logic EP93xx CPU Rafal Prylowski
2012-03-29  8:10 ` Rafal Prylowski
2012-03-29  8:17 ` [PATCH 1/3] PATA host controller driver for ep93xx Rafal Prylowski
2012-03-29  8:17   ` Rafal Prylowski
2012-03-29 17:25   ` H Hartley Sweeten
2012-03-29 17:25     ` H Hartley Sweeten
2012-03-30  8:13     ` Rafal Prylowski
2012-03-30  8:13       ` Rafal Prylowski
2012-03-29 22:21   ` Ryan Mallon
2012-03-29 22:21     ` Ryan Mallon
2012-03-30 10:13     ` Rafal Prylowski
2012-03-30 10:13       ` Rafal Prylowski
2012-03-29 22:24   ` Ryan Mallon
2012-03-29 22:24     ` Ryan Mallon
2012-03-30  8:19     ` Rafal Prylowski
2012-03-30  8:19       ` Rafal Prylowski
2012-03-30 20:18   ` Arnd Bergmann
2012-03-30 20:18     ` Arnd Bergmann
2012-04-02  7:52     ` Rafal Prylowski
2012-04-02  7:52       ` Rafal Prylowski
2012-04-02  8:08       ` Arnd Bergmann
2012-04-02  8:08         ` Arnd Bergmann
2012-04-02  9:28         ` Rafal Prylowski [this message]
2012-04-02  9:28           ` Rafal Prylowski
2012-04-02 10:24           ` Arnd Bergmann
2012-04-02 10:24             ` Arnd Bergmann
2012-04-03  1:50       ` Ryan Mallon
2012-04-03  1:50         ` Ryan Mallon
2012-04-03  7:41         ` Arnd Bergmann
2012-04-03  7:41           ` Arnd Bergmann
2012-03-29  8:19 ` [PATCH 2/3] ep93xx: IDE driver platform support code Rafal Prylowski
2012-03-29  8:19   ` Rafal Prylowski
2012-03-29 16:26   ` H Hartley Sweeten
2012-03-29 16:26     ` H Hartley Sweeten
2012-03-30  8:29     ` Rafal Prylowski
2012-03-30  8:29       ` Rafal Prylowski
2012-03-29  8:20 ` [PATCH 3/3] ep93xx: Add IDE support to edb93xx boards Rafal Prylowski
2012-03-29  8:20   ` Rafal Prylowski
2012-03-29 16:32   ` H Hartley Sweeten
2012-03-29 16:32     ` H Hartley Sweeten
2012-03-30  8:32     ` Rafal Prylowski
2012-03-30  8:32       ` Rafal Prylowski

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=4F797144.400@metasoft.pl \
    --to=prylowski@metasoft.pl \
    --cc=arnd@arndb.de \
    --cc=bzolnier@gmail.com \
    --cc=hsweeten@visionengravers.com \
    --cc=joao.ramos@inov.pt \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=rmallon@gmail.com \
    --cc=sshtylyov@mvista.com \
    /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.