public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nick Warne <nick@ukfsn.org>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
	Greg KH <greg@kroah.com>, Kay Sievers <kay.sievers@vrfy.org>
Subject: Re: Driver 'sd' needs updating
Date: Thu, 10 Jan 2008 18:51:51 +0000	[thread overview]
Message-ID: <20080110185151.5945f650@linuxamd.linicks.net> (raw)
In-Reply-To: <1199989642.3141.66.camel@localhost.localdomain>

On Thu, 10 Jan 2008 12:27:22 -0600
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:


> > > OK, updated to git rc7 yesterday - I now see this in syslog:
>
>    "Driver 'sd' needs updating - please use bus_type methods"
>
> > > Do I need to fix up something here?
> > 
> > No, you don't. It's harmless, a side effect of:
> > 
> > commit 751bf4d7865e4ced406be93b04c7436d866d3684
> > Author: James Bottomley <James.Bottomley@HansenPartnership.com>
> > Date:   Wed Jan 2 11:14:30 2008 -0600
> > 
> >     [SCSI] scsi_sysfs: restore prep_fn when ULD is removed
> > 
> > 
> > It would be better to silence this warning.
> > 
> > James, we need to reset prep_fn in each ULD? though it's not nice...
> 
> Really not nice ... to the extent that we shouldn't do it.  The reset
> is in exactly the correct place currently.  If we make it a
> requirement of the ULDs its duplication and someone is bound to
> forget.
> 
> It looks like the problem is the warning in
> base/driver.c:driver_register() apparently it wants an either/or for
> ->remove methods (either bus type or driver).  We're actually using
> the bus_type methods, but we also have a driver component, sigh.  I
> suppose what it's wanting is for me to add a scsi_driver type with
> remove methods ... which looks a bit silly since all of the SCSI
> drivers want different remove methods.

OK, actually, this is wierd for me now.  Is this warning ONLY generated
on modules?

I build with no modules, but do have modules enabled due to nVidia.  I
did post about a module called 'scsi_wait' being built, even though I
didn't want it/need it but can't stop it - please refer:

http://marc.info/?t=119705493500007&r=1&w=2

If this is true, what I have now is a module being built I don't
want/need and can't stop it being built, and a warning about it not
using bus_type methods anyway.

Nick
-- 
Free Software Foundation Associate Member 5508

      reply	other threads:[~2008-01-10 18:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-10  8:51 Driver 'sd' needs updating Nick Warne
2008-01-10 11:38 ` FUJITA Tomonori
2008-01-10 17:41   ` Nick Warne
2008-01-10 18:27   ` James Bottomley
2008-01-10 18:51     ` Nick Warne [this message]

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=20080110185151.5945f650@linuxamd.linicks.net \
    --to=nick@ukfsn.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=greg@kroah.com \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@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