RE: [PATCH 3/3] drivers: Add visorbus to the drivers/virt directory

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: Greg KH [mailto:gregkh@xxxxxxxxxxxxxxxxxxx]
> Sent: Sunday, August 21, 2016 2:05 PM
> To: Kershner, David A <David.Kershner@xxxxxxxxxx>
> Cc: corbet@xxxxxxx; tglx@xxxxxxxxxxxxx; mingo@xxxxxxxxxx;
> hpa@xxxxxxxxx; Arfvidson, Erik <Erik.Arfvidson@xxxxxxxxxx>; Sell, Timothy
> C <Timothy.Sell@xxxxxxxxxx>; hofrat@xxxxxxxxx; dzickus@xxxxxxxxxx;
> jes.sorensen@xxxxxxxxxx; Curtin, Alexander Paul
> <Alexander.Curtin@xxxxxxxxxx>; janani.rvchndrn@xxxxxxxxx;
> sudipm.mukherjee@xxxxxxxxx; prarit@xxxxxxxxxx; Binder, David Anthony
> <David.Binder@xxxxxxxxxx>; nhorman@xxxxxxxxxx;
> dan.j.williams@xxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux-
> doc@xxxxxxxxxxxxxxx; driverdev-devel@xxxxxxxxxxxxxxxxxxxxxx; *S-Par-
> Maintainer <SParMaintainer@xxxxxxxxxx>
> Subject: Re: [PATCH 3/3] drivers: Add visorbus to the drivers/virt directory
> 
> On Fri, Jun 10, 2016 at 11:23:56PM -0400, David Kershner wrote:
> > visorbus is currently located at drivers/staging/visorbus,
> > this patch moves it to drivers/virt.
> >
> > Signed-off-by: David Kershner <david.kershner@xxxxxxxxxx>
> > Reviewed-by: Tim Sell <Timothy.Sell@xxxxxxxxxx>
> > ---
> >  drivers/staging/unisys/Kconfig                                        | 3 +--
> >  drivers/staging/unisys/Makefile                                       | 1 -
> >  drivers/virt/Kconfig                                                  | 2 ++
> >  drivers/virt/Makefile                                                 | 1 +
> >  drivers/{staging/unisys => virt}/visorbus/Kconfig                     | 0
> >  drivers/{staging/unisys => virt}/visorbus/Makefile                    | 0
> >  drivers/{staging/unisys => virt}/visorbus/controlvmchannel.h          | 0
> >  drivers/{staging/unisys => virt}/visorbus/controlvmcompletionstatus.h | 0
> >  drivers/{staging/unisys => virt}/visorbus/iovmcall_gnuc.h             | 0
> >  drivers/{staging/unisys => virt}/visorbus/vbuschannel.h               | 0
> >  drivers/{staging/unisys => virt}/visorbus/vbusdeviceinfo.h            | 0
> >  drivers/{staging/unisys => virt}/visorbus/vbushelper.h                | 0
> >  drivers/{staging/unisys => virt}/visorbus/visorbus_main.c             | 0
> >  drivers/{staging/unisys => virt}/visorbus/visorbus_private.h          | 0
> >  drivers/{staging/unisys => virt}/visorbus/visorchannel.c              | 0
> >  drivers/{staging/unisys => virt}/visorbus/visorchipset.c              | 0
> 
> I picked one random file here, this last one, and found a number of
> "odd" things in it.
> 
> So, given that I can't really comment on the patch itself, I'm going to
> include the file below, quote it, and then provide some comments, ok?
> > /* visorchipset_main.c
> > ...
> > static void
> > controlvm_init_response(struct controlvm_message *msg,
> > 			struct controlvm_message_header *msg_hdr, int response)
> > {
> > 	memset(msg, 0, sizeof(struct controlvm_message));
> > 	memcpy(&msg->hdr, msg_hdr, sizeof(struct controlvm_message_header));
> > 	msg->hdr.payload_bytes = 0;
> > 	msg->hdr.payload_vm_offset = 0;
> > 	msg->hdr.payload_max_bytes = 0;
> > 	if (response < 0) {
> > 		msg->hdr.flags.failed = 1;
> > 		msg->hdr.completion_status = (u32)(-response);
> > 	}
> > }
> > 
> > static void
> > Billy(struct controlvm_message_header *msg_hdr, int response)
> 
> Not John?  Bob?  Sally?  Alice?  Bernise?  Jean?  Molly?

Huh? What version of source code are you looking at??

The file being moved by this patch should be
drivers/staging/unisys/visorbus/visorchipset.c in your staging-next branch  
(https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/tree/drivers/staging/unisys/visorbus/visorchipset.c?h=staging-next).
If you look there, you will NOT find "Billy()", but instead "controlvm_respond()", i.e.:

static void
controlvm_init_response(struct controlvm_message *msg,
			struct controlvm_message_header *msg_hdr, int response)
{
	memset(msg, 0, sizeof(struct controlvm_message));
	memcpy(&msg->hdr, msg_hdr, sizeof(struct controlvm_message_header));
	msg->hdr.payload_bytes = 0;
	msg->hdr.payload_vm_offset = 0;
	msg->hdr.payload_max_bytes = 0;
	if (response < 0) {
		msg->hdr.flags.failed = 1;
		msg->hdr.completion_status = (u32)(-response);
	}
}

static void
controlvm_respond(struct controlvm_message_header *msg_hdr, int response)
{
	struct controlvm_message outmsg;

	controlvm_init_response(&outmsg, msg_hdr, response);
	if (outmsg.hdr.flags.test_message == 1)
		return;

	if (!visorchannel_signalinsert(controlvm_channel,
				       CONTROLVM_QUEUE_REQUEST, &outmsg)) {
		return;
	}
}

One (or both) of us is confused.

Tim Sell

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux