linux-kernel - Re: [PATCH 2/3] staging: vme: add struct vme

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4E609BAF.2020102@ge.com>
Date:	Fri, 02 Sep 2011 10:02:39 +0100
From:	Martyn Welch <martyn.welch@...com>
To:	Manohar Vanga <manohar.vanga@...n.ch>
CC:	gregkh@...e.de, cota@...ap.org, devel@...verdev.osuosl.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] staging: vme: add struct vme_dev for VME devices

On 01/09/11 10:15, Manohar Vanga wrote:
> diff --git a/drivers/staging/vme/vme.h b/drivers/staging/vme/vme.h
> index 4155d8c..d442cce 100644
> --- a/drivers/staging/vme/vme.h
> +++ b/drivers/staging/vme/vme.h
> @@ -91,17 +91,34 @@ extern struct bus_type vme_bus_type;
>  #define VME_SLOT_CURRENT	-1
>  #define VME_SLOT_ALL		-2
>  
> +/**
> + * VME device identifier structure
> + * @bus: The bus ID of the bus the device is on
> + * @slot: The slot this device is plugged into
> + */
>  struct vme_device_id {
>  	int bus;
>  	int slot;
>  };
>  
> +/**
> + * Structure representing a VME device
> + * @id: The ID of the device (currently the bus and slot number)
> + * @bridge: Pointer to the bridge device this device is on
> + * @dev: Internal device structure
> + */
> +struct vme_dev {
> +	struct vme_device_id id;
> +	struct vme_bridge *bridge;
> +	struct device dev;
> +};
> +

I think we can probably merge vme_device_id and vme_dev.

Since we have a pointer to the vme_bridge, the bus number in vme_device_id is
kinda superfluous.

The direction we are heading in makes the slot number far less important, in
some ways it becomes more of an optional information field (in pre-vme64 racks
we probably won't know which slot the device we are bound to is in anyway).
Basically moving from a binding mechanism like PCI to a binding mechanism
closer to ISA, which matches the (widely used, more historic subset) of
capabilites of the VME bus. I think we can just move the slot number to
vme_dev and do away with vme_device_id entirely.

Martyn


-- 
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms                   | Wales (3828642) at 100
T +44(0)1327322748                         | Barbirolli Square, Manchester,
E martyn.welch@...com                      | M2 3AB  VAT:GB 927559189
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/