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
next prev parent reply other threads:[~2012-04-02 9:28 UTC|newest]
Thread overview: 21+ 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:17 ` [PATCH 1/3] PATA host controller driver for ep93xx Rafal Prylowski
2012-03-29 17:25 ` H Hartley Sweeten
2012-03-30 8:13 ` Rafal Prylowski
2012-03-29 22:21 ` Ryan Mallon
2012-03-30 10:13 ` Rafal Prylowski
2012-03-29 22:24 ` Ryan Mallon
2012-03-30 8:19 ` Rafal Prylowski
2012-03-30 20:18 ` Arnd Bergmann
2012-04-02 7:52 ` Rafal Prylowski
2012-04-02 8:08 ` Arnd Bergmann
2012-04-02 9:28 ` Rafal Prylowski [this message]
2012-04-02 10:24 ` Arnd Bergmann
2012-04-03 1:50 ` Ryan Mallon
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 16:26 ` H Hartley Sweeten
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 16:32 ` H Hartley Sweeten
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$(echo .)pl \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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