All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Tejun Heo <htejun@gmail.com>
Cc: "linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>
Subject: Re: [git-patch] hotplug fix patches added
Date: Mon, 12 Jun 2006 09:41:29 -0400	[thread overview]
Message-ID: <448D6F09.3080609@pobox.com> (raw)
In-Reply-To: <448C1FA7.6030305@gmail.com>

Tejun Heo wrote:
> Jeff Garzik wrote:
>> Tejun Heo wrote:
>>> Hello,
>>>
>>> Two hotplug fix patches have been added to libata-tj #for-jeff.
>>>
>>> * libata: add missing finish_wait() call in ata_port_wait_eh()
>>> * libata: cosmetic change in struct ata_port
>>>
>>> The following two patches have been dropped as it hasn't been acked yet.
>>>
>>> * ata_piix: fix ghost device probing by honoring PCS present bits[1]
>>
>> Seems vaguely OK to me...
>>
>>
>>> * libata: add ata_port->private_flags[2]
>>
>> What's the justification for this?  Running out of room in flags?
> 
> Yeap, ran out of bits while implementing power management.
> 
>> If we are going to do this, I would move any such flags to the 
>> LLDD-allocated hpriv structure completely.  I wouldn't add hpriv_flags 
>> to struct ata_port.
> 
> Several drivers only need flags.  IMHO, having to allocate hpriv just 
> for flags is a bit annoying.  I also thought about separating capability 
> flags and dynamic flags but couldn't think of proper field name. 
> ap->dyn_flags?  Also, it would be easy to screw up and test the wrong 
> field.  Another sucky option was using u64 for flags.

I tend to think that most drivers fall into two categories:

* bmdma (PCI IDE-like) drivers
* drivers which already do their own hpriv allocation and management

Therefore, I would be OK with adding a bmdma_flags member, to be used 
only by bmdma drivers [and eventually separated from the high level 
libata API, as discussed].  Otherwise, I would go ahead and add code to 
allocate an hpriv structure in the driver.

	Jeff




  reply	other threads:[~2006-06-12 13:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-11  2:29 [git-patch] hotplug fix patches added Tejun Heo
2006-06-11 13:35 ` Jeff Garzik
2006-06-11 13:50   ` Tejun Heo
2006-06-12 13:41     ` Jeff Garzik [this message]
2006-06-12 13:46       ` Tejun Heo
2006-06-11 13:51 ` 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=448D6F09.3080609@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=htejun@gmail.com \
    --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 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.