On Wed, 29 Mar 2017 23:48:44 +0300
"Michael S. Tsirkin" wrote:
> We are going to add more parameters to find_vqs, let's wrap the call so
> we don't need to tweak all drivers every time.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> drivers/block/virtio_blk.c | 3 +--
> drivers/
On Thu, 8 Dec 2016 04:29:39 +0200
"Michael S. Tsirkin" wrote:
> By now, linux is mostly endian-clean. Enabling endian-ness
> checks for everyone produces about 200 new sparse warnings for me -
> less than 10% over the 2000 sparse warnings already there.
Out of curiousity: Where do most of those
On Mon, 1 Dec 2014 14:53:05 +0200
"Michael S. Tsirkin" wrote:
> On Mon, Dec 01, 2014 at 01:50:01PM +0100, Cornelia Huck wrote:
> > On Sun, 30 Nov 2014 17:12:47 +0200
> > "Michael S. Tsirkin" wrote:
> >
> > > Note: for consistency, and to avo
On Sun, 30 Nov 2014 17:12:47 +0200
"Michael S. Tsirkin" wrote:
> Note: for consistency, and to avoid sparse errors,
> convert all fields, even those no longer in use
> for virtio v1.0.
>
> Signed-off-by: Michael S. Tsirkin
> Acked-by: Paolo Bonzini
> ---
> include/linux/virtio_scsi.h | 32
On Tue, 25 Nov 2014 18:44:08 +0200
"Michael S. Tsirkin" wrote:
> Note: for consistency, and to avoid sparse errors,
> convert all fields, even those no longer in use
> for virtio v1.0.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> include/linux/virtio_scsi.h | 32 +++---
On Mon, 20 Oct 2014 13:07:50 +0100
Thomas Graf wrote:
> On 10/13/14 at 10:50am, Michael S. Tsirkin wrote:
> > virtio spec requires drivers to set DRIVER_OK before using VQs.
> > This is set automatically after probe returns, virtio console violated this
> > rule by adding inbufs, which causes the
On Fri, 11 Jan 2008 10:33:16 +0800,
"Dave Young" <[EMAIL PROTECTED]> wrote:
> > > +struct device *class_find_device(struct class *class, void *data,
> > > +int (*match)(struct device *, void *))
> > > +{
> > > + struct device *dev;
> > > +
> > > + if (!clas
On Thu, 10 Jan 2008 17:48:43 +0800,
Dave Young <[EMAIL PROTECTED]> wrote:
Please add a kerneldoc comment for each of the new interfaces.
> +int class_for_each_device(struct class *class, void *data,
> +int (*fn)(struct device *, void *))
> +{
> + struct device *dev;
>
On Wed, 31 Oct 2007 11:37:36 +0100,
Stefan Richter <[EMAIL PROTECTED]> wrote:
> > mask_out() would also imply that the common use case is to have all
> > attributes in the group created and that you need to take action to
> > have an attribute not created.
>
> Here you have a point. But James ha
On Wed, 31 Oct 2007 10:52:35 +0100,
Stefan Richter <[EMAIL PROTECTED]> wrote:
> Cornelia Huck wrote:
> > Greg KH <[EMAIL PROTECTED]> wrote:
> >> On Tue, Oct 30, 2007 at 01:25:43PM -0500, James Bottomley wrote:
> >>> + for (i = 0, attr = grp->attrs
On Tue, 30 Oct 2007 20:55:06 -0700,
Greg KH <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 30, 2007 at 01:25:43PM -0500, James Bottomley wrote:
> > Index: BUILD-2.6/fs/sysfs/group.c
> > ===
> > --- BUILD-2.6.orig/fs/sysfs/group.c 2007-10-28
On Mon, 29 Oct 2007 12:29:27 -0500,
James Bottomley <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-10-29 at 13:27 -0400, Jeff Garzik wrote:
> > James Bottomley wrote:
> > > visibility and creation are the same thing, aren't they? An invisible
> > > attribute doesn't appear in the sysfs directory, so i
On Mon, 29 Oct 2007 12:24:06 -0500,
James Bottomley <[EMAIL PROTECTED]> wrote:
> > Can you determine which subset of the attributes you want just before
> > actually creating the group? Then you could do something like:
> >
> > create_group(grp, kobj)
> > {
> > grp->update_creation_mask(kobj)
On Mon, 29 Oct 2007 11:57:51 -0500,
James Bottomley <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-10-29 at 17:54 +0100, Kay Sievers wrote:
> > On Mon, 2007-10-29 at 10:16 -0500, James Bottomley wrote:
> > > This patch is a first pass at adding a filter function to the group
> > > attributes, just to s
On Thu, 19 Jul 2007 14:13:33 +0200 (CEST),
Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> Any chance this will change? I already added a mutex to ps3disk to protect
> against this.
Probably not in the near future. A mutex looks like a good idea though,
since one never knows (and the driver core
On Thu, 19 Jul 2007 11:36:31 +0200 (CEST),
Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> We have a probe thread that checks for new storage devices and adds them to
> the
> bus with ps3_system_bus_device_register(), which calls device_register().
>
> I guess the actual bus probe() routine gets
On Thu, 19 Jul 2007 10:57:53 +0200 (CEST),
Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> Were .probe()/.remove() made concurrent again? I thought that idea was dropped
> because it caused too many problems?
Well, for a given device, ->probe()/->remove() are locked by dev->sem,
so that there can
On Thu, 31 May 2007 15:10:05 -0700,
Andrew Morton <[EMAIL PROTECTED]> wrote:
> Cornelia, afaict your patch has no actual delendency upon Dan's
> dma-mapping-prevent-dma-dependent-code-from-linking-on.patch, correct? If
> so, I can merge it via James and then merge Dan's patch once James has
> mer
On Thu, 31 May 2007 08:35:13 -0400,
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Cornelia Huck wrote:
> > On Thu, 31 May 2007 06:15:57 -0600,
> > Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> >
> >> On Thu, May 31, 2007 at 02:09:22PM +0200, Cornelia Huck wrote
On Thu, 31 May 2007 06:15:57 -0600,
Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> On Thu, May 31, 2007 at 02:09:22PM +0200, Cornelia Huck wrote:
> > I split those functions out into a new file. Builds on s390 and i386.
>
> Why not just put #ifdef CONFIG_HAS_DMA / #end
s390 and i386.
scsi: Don't build scsi_dma_{map,unmap} for !HAS_DMA
Move scsi_dma_{map,unmap} into scsi_lib_dma.c which is only build
if HAS_DMA is set.
Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]>
---
drivers/scsi/Kconfig|5
drivers/scsi/Makefile |
On Mon, 2 Apr 2007 11:20:48 +0200,
Cornelia Huck <[EMAIL PROTECTED]> wrote:
> Cool. However, there's something fishy there (not sure whether it's in
> your patch or a latent bug in the ccw bus code that just has been
> uncovered):
Similar bug when loading/unloading a mod
On Mon, 2 Apr 2007 04:59:43 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Okay, here's preliminary patch. I've tested it very lightly so it's
> likely to contain bugs and definitely needs to be splitted.
Cool. However, there's something fishy there (not sure whether it's in
your patch or a laten
On Sat, 31 Mar 2007 12:12:48 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> > Hm, but as long as dk0 is registered, it can be looked up and someone
> > could get a reference on it.
>
> Yeah, exactly. That's why any getting any kobject reference backed by a
> module must be accompanied by try_modu
On Sat, 31 Mar 2007 00:08:19 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> (3) make sure all existing kobjects are released by module exit function.
>
> For example, let's say there is a hypothetical disk device /dev/dk0
> driven by a hypothetical driver mydrv. /dev/dk0 is represented like the
>
On Fri, 30 Mar 2007 22:58:39 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> It's a little bit more convoluted than that. Module reference count of
> zero doesn't indicate that there is no one referencing the module. It
> just means that the module can be unloaded. ie. There still can be any
> nu
On Fri, 30 Mar 2007 22:19:52 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> > Shouldn't getting/putting the module refcount be solely done in
> > kobject.c? Grab the module reference when the kobject is created and
> > release the module reference in kobject_cleanup() after the release
> > function
On Fri, 30 Mar 2007 18:43:02 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> One way to solve this problem is to subordinate lifetime rule #b to
> rule #c. Each kobject points to its owning module such that grabbing
> a kobject automatically grabs the module. The problem with this
> approach is th
28 matches
Mail list logo
