From: Tejun Heo <htejun@gmail.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: jeff@garzik.org, linux-ide@vger.kernel.org
Subject: Re: [PATCH 05/12] libata: xfer_mask is unsigned int not unsigned long
Date: Tue, 06 Nov 2007 19:59:03 +0900 [thread overview]
Message-ID: <473048F7.2050004@gmail.com> (raw)
In-Reply-To: <20071106105151.2e3d15b8@the-village.bc.nu>
Alan Cox wrote:
> On Tue, 6 Nov 2007 14:39:03 +0900
> Tejun Heo <htejun@gmail.com> wrote:
>
>> xfer_mask is unsigned int not unsigned long. Change ->mode_filter to
>> take and return unsigned int.
>>
>> While at it, rename @adev of ata_pci_default_filter() to @dev for
>> consistency.
>>
>> Signed-off-by: Tejun Heo <htejun@gmail.com>
>
> The filter type was purposefully unsigned long to allow for expansion (eg
> for SWDMA) without breaking drivers. No problem with it changing but I'd
> say "unsigned int" was the worst possible choice - its now shorter (no
> room for expansion) and size dependant on arch. u32 would be shorter and
> consistent across all platforms, ulong would have more room for expansion.
I agree it should be one of u* types and am happy to convert. This
patch is primarily for consistency as in libata-core, xfer_mask is
unsigned int. My first proposal was u32 too but Jeff vetoed it. IIRC,
Jeff has affection for machine-independent integral types. :-)
Anyways, I think ulong is worse than uint because ulong differs in size
between 32 and 64 archs. What's the good of extra 32bits in flags space
if it's not there on 32bit archs? Also, we currently only use 20bits of
xfermask, 12 extra bits seem enough for the time, especially as
everything is moving over to SATA where xfermode doesn't really matter, no?
Jeff, are you okay with u32 or 64?
--
tejun
next prev parent reply other threads:[~2007-11-06 10:59 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-06 5:38 [PATCHSET] libata: update timing and fix pata_amd transfer mode selection Tejun Heo
2007-11-06 5:38 ` [PATCH 01/12] ata_generic: unindent loop in generic_set_mode() Tejun Heo
2007-11-06 5:39 ` [PATCH 02/12] libata: export xfermode / PATA timing related functions Tejun Heo
2007-11-06 5:39 ` [PATCH 03/12] libata: clean up xfermode / PATA timing related stuff Tejun Heo
2007-11-06 5:39 ` [PATCH 04/12] libata: kill ata_id_to_dma_mode() Tejun Heo
2007-11-06 10:49 ` Alan Cox
2007-11-06 11:21 ` Tejun Heo
2007-11-24 1:13 ` Jeff Garzik
2007-11-06 5:39 ` [PATCH 05/12] libata: xfer_mask is unsigned int not unsigned long Tejun Heo
2007-11-06 10:51 ` Alan Cox
2007-11-06 10:59 ` Tejun Heo [this message]
2007-11-06 17:53 ` Jeff Garzik
2007-11-07 1:12 ` Tejun Heo
2007-11-24 1:13 ` Jeff Garzik
2007-11-24 1:13 ` Jeff Garzik
2007-11-27 8:42 ` Tejun Heo
2007-11-06 5:39 ` [PATCH 06/12] libata: separate out ata_acpi_gtm_xfermask() from pacpi_discover_modes() Tejun Heo
2007-11-06 10:54 ` Alan Cox
2007-11-06 11:00 ` Tejun Heo
2007-11-24 1:14 ` Jeff Garzik
2007-11-06 5:39 ` [PATCH 07/12] libata: fix ata_acpi_gtm_xfermask() Tejun Heo
2007-11-06 10:55 ` Alan Cox
2007-11-24 1:16 ` Jeff Garzik
2007-11-27 8:40 ` Tejun Heo
2007-11-06 5:39 ` [PATCH 08/12] libata: implement ata_timing_cycle2mode() and use it in libata-acpi and pata_acpi Tejun Heo
2007-11-06 10:59 ` Alan Cox
2007-11-06 11:09 ` Tejun Heo
2007-11-24 1:17 ` Jeff Garzik
2007-11-06 5:39 ` [PATCH 09/12] libata: implement ata_acpi_init_gtm() Tejun Heo
2007-11-06 5:39 ` [PATCH 10/12] libata: reimplement ata_acpi_cbl_80wire() using ata_acpi_gtm_xfermask() Tejun Heo
2007-11-06 5:39 ` [PATCH 11/12] libata: add ATA_CBL_PATA_IGN Tejun Heo
2007-11-06 10:59 ` Alan Cox
2007-11-06 11:02 ` Tejun Heo
2007-11-06 11:25 ` Alan Cox
2007-11-06 5:39 ` [PATCH 12/12] pata_amd: update mode selection for NV PATAs Tejun Heo
2007-11-06 10:59 ` Alan Cox
2007-11-23 1:08 ` [PATCHSET] libata: update timing and fix pata_amd transfer mode selection Tejun Heo
2007-11-24 1:18 ` Jeff Garzik
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=473048F7.2050004@gmail.com \
--to=htejun@gmail.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jeff@garzik.org \
--cc=linux-ide@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 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).