From: Mark Lord <liml@rtr.ca>
To: Byron Bradley <byron.bbradley@gmail.com>, saeed@marvell.com
Cc: linux-ide@vger.kernel.org, mlord@pobox.com, jeff@garzik.org,
linux-arm-kernel@lists.arm.linux.org.uk
Subject: Re: sata_mv: problems using it as a platform_driver
Date: Thu, 07 Feb 2008 23:42:38 -0500 [thread overview]
Message-ID: <47ABDDBE.4060607@rtr.ca> (raw)
In-Reply-To: <alpine.DEB.1.00.0802080217070.16853@git.byronbradley.co.uk>
Byron Bradley wrote:
> On Fri, 8 Feb 2008, Byron Bradley wrote:
>
>> I'm having problems getting the sata_mv driver working as a platform
>> driver on the QNAP TS-209 and the Linkstation/Kurobox (both are Marvell
>> Orion 88f5182 based devices). First of all it would oops in
>> mv_port_start() while calling dma_pool_alloc(), the patch to fix this is
>> at the end of this email.
>>
>> In mv_platform_probe() host->iomap is set to NULL but it is dereferenced
>> in mv_start_dma(), I'm not sure what the fix for this is. This is based on
>> the latest 2.6-git and a merge with the for-rmk branch of the orion git.
>
> The following patch makes this driver work although I have no idea if this
> is the correct thing to do. Will this be OK for other devices using this
> driver? The pointer only works because it is dereferenced as
> iomap[MV_PRIMARY_BAR] and MV_PRIMARY_BAR = 0, will another offset ever be
> used in the future?
>
> diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
> index 04b5717..b538ccc 100644
> --- a/drivers/ata/sata_mv.c
> +++ b/drivers/ata/sata_mv.c
> @@ -2950,8 +2950,8 @@ static int mv_platform_probe(struct platform_device *pdev)
> host->private_data = hpriv;
> hpriv->n_ports = n_ports;
>
> - host->iomap = NULL;
> hpriv->base = ioremap(res->start, res->end - res->start + 1);
> + host->iomap = &hpriv->base;
> hpriv->base -= MV_SATAHC0_REG_BASE;
>
> rc = mv_create_dma_pools(hpriv, &pdev->dev);
..
Well, that's definitely one way to attack it.
The original problem being, for a non-PCI device, there is no iomap[] table.
sata_mv only ever uses iomap[MV_PRIMARY_BAR=0], so the above patch should
work around it just fine.
Dunno how that maps to Jeff's taste in code, though. :)
How do other platform drivers deal with this?
Saeed -- homework for you.
Cheers
next prev parent reply other threads:[~2008-02-08 4:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-08 1:33 sata_mv: problems using it as a platform_driver Byron Bradley
2008-02-08 2:20 ` Byron Bradley
2008-02-08 4:42 ` Mark Lord [this message]
2008-02-11 13:35 ` Saeed Bishara
2008-02-12 1:31 ` Tejun Heo
2008-02-08 4:35 ` Mark Lord
2008-02-11 13:06 ` Saeed Bishara
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=47ABDDBE.4060607@rtr.ca \
--to=liml@rtr.ca \
--cc=byron.bbradley@gmail.com \
--cc=jeff@garzik.org \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=linux-ide@vger.kernel.org \
--cc=mlord@pobox.com \
--cc=saeed@marvell.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 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).