Re: [char-misc-next 03/11] mei: bus: Initial implementation for I/O routines
On Monday 11 February 2013 16:48:12 Samuel Ortiz wrote: > > > If so, how do you know which transport to use? > Through the mei_bus_client ops. Device drivers get a mei_bus_client pointer > from their probe routine and the ops pointers there (If any) are set by > whoever creates the device. In the NFC case mei/nfc.c does that and implements > the NFC specific transport code for this technology. mei/nfc.c is also the > part of the code that actually adds the device to the bus. Ok. > So when a device driver wants e.g. to send its payload through the MEI bus, it > calls mei_bus_send() which takes the device driver mei_bus client pointer as > its first argument. > Then the payload may go through mei_bus_client->send() first which will > eventually > physically sent the newly built frame through mei_send(). Some ME blocks > don't require any > additional transport layer and in that case the device driver payload will go > straight to mei_send() since the mei_bus_client ops will be NULL. > > Does that make more sense now ? Yes, so it's not actually as complicated as I thought, because the operations are already known by the bus driver (in the normal sense of that word, meaning the driver that creates the device not the one driving it) at the time when the device is created. In that case, please ignore my original comment and put the struct mei_bus_ops (mei_transport_ops?) back, ideally as a "const" member of the struct mei_bus_device (to be called mei_device then), so you can declare the structure statically and constant in the driver that has the functions. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [char-misc-next 03/11] mei: bus: Initial implementation for I/O routines
Hi Arnd,
On Mon, Feb 11, 2013 at 03:08:24PM +, Arnd Bergmann wrote:
> On Monday 11 February 2013, Samuel Ortiz wrote:
> > On Mon, Feb 11, 2013 at 11:52:42AM +, Arnd Bergmann wrote:
> > > On Thursday 07 February 2013, Samuel Ortiz wrote:
> > > > On Thu, Feb 07, 2013 at 10:34:44PM +, Arnd Bergmann wrote:
> > > > > On Thursday 07 February 2013, Tomas Winkler wrote:
> > > > > > +
> > > > > > +struct mei_bus_ops {
> > > > > > + int (*send)(struct mei_bus_client *client, u8 *buf, size_t
> > > > > > length);
> > > > > > + int (*recv)(struct mei_bus_client *client, u8 *buf, size_t
> > > > > > length);
> > > > > > +};
> > > > > > +
> > > > >
> > > > > Can you have more than one set of mei_bus_ops in a driver?
> > > > You can have at most one mei_bus_ops per mei_bus_client.
> > > >
> > > > > If not, how about adding the callbacks to the mei_bus_driver structure
> > > > > directly as a simplification?
> > > > I can add the ops directly to the mei_bus_client structure, yes.
> > >
> > > I looked at the new version, and it's not what I assumed it would be.
> > > I thought the operations were specific to a client driver and should
> > > be part of the /mei_bus_driver/ structure, not the /mei_bus_client/.
> > The ops should be part of mei_bus_client as they're specific to the MEI
> > protocol for a given IP block on the ME. You need to have MEI and HECI
> > knowledge to implement those ops and drivers (defining their mei_bus_driver
> > structure) should not have that kind of knowledge but rather focus on the
> > technology they're driving.
> > If we take the NFC example again, the drivers/nfc/ code will send NFC
> > payloads
> > to the bus I/O routines and this is where the mei_bus_client ops will add
> > the
> > ME specific protocol (command and request id for the NFC block) on top of
> > it.
> > In practice, this is an additional header which handles a transport layer
> > that's
> > specific not only to the ME but to the NFC block of it. So each ME block can
> > have its own protocol to send and receive technology specific payloads,
> > that's
> > what those ops implement.
> > That's why I think that those ops should not be defined by the drivers/nfc/
> > code
> > and in fact should be opaque to it.
>
> I think I'm still confused.
It is confusing, and my explanations are probably not as good as they should
be.
> What I read in your description is that unlike
> other subsystems that have a common bus implementation that is hooked into
> by two kinds of drivers (bus drivers that provide devices like a USB host
> controller, and device drivers that use those devices), you have three
> components that can be mixed independently: the bus (based on which
> PCI device you have), the transport and the endpoint device. Is that
> correct?
That's quite accurate, yes.
> If so, how do you know which transport to use?
Through the mei_bus_client ops. Device drivers get a mei_bus_client pointer
from their probe routine and the ops pointers there (If any) are set by
whoever creates the device. In the NFC case mei/nfc.c does that and implements
the NFC specific transport code for this technology. mei/nfc.c is also the
part of the code that actually adds the device to the bus.
So when a device driver wants e.g. to send its payload through the MEI bus, it
calls mei_bus_send() which takes the device driver mei_bus client pointer as
its first argument.
Then the payload may go through mei_bus_client->send() first which will
eventually
physically sent the newly built frame through mei_send(). Some ME blocks don't
require any
additional transport layer and in that case the device driver payload will go
straight to mei_send() since the mei_bus_client ops will be NULL.
Does that make more sense now ?
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [char-misc-next 03/11] mei: bus: Initial implementation for I/O routines
On Monday 11 February 2013, Samuel Ortiz wrote:
> On Mon, Feb 11, 2013 at 11:52:42AM +, Arnd Bergmann wrote:
> > On Thursday 07 February 2013, Samuel Ortiz wrote:
> > > On Thu, Feb 07, 2013 at 10:34:44PM +, Arnd Bergmann wrote:
> > > > On Thursday 07 February 2013, Tomas Winkler wrote:
> > > > > +
> > > > > +struct mei_bus_ops {
> > > > > + int (*send)(struct mei_bus_client *client, u8 *buf, size_t
> > > > > length);
> > > > > + int (*recv)(struct mei_bus_client *client, u8 *buf, size_t
> > > > > length);
> > > > > +};
> > > > > +
> > > >
> > > > Can you have more than one set of mei_bus_ops in a driver?
> > > You can have at most one mei_bus_ops per mei_bus_client.
> > >
> > > > If not, how about adding the callbacks to the mei_bus_driver structure
> > > > directly as a simplification?
> > > I can add the ops directly to the mei_bus_client structure, yes.
> >
> > I looked at the new version, and it's not what I assumed it would be.
> > I thought the operations were specific to a client driver and should
> > be part of the /mei_bus_driver/ structure, not the /mei_bus_client/.
> The ops should be part of mei_bus_client as they're specific to the MEI
> protocol for a given IP block on the ME. You need to have MEI and HECI
> knowledge to implement those ops and drivers (defining their mei_bus_driver
> structure) should not have that kind of knowledge but rather focus on the
> technology they're driving.
> If we take the NFC example again, the drivers/nfc/ code will send NFC payloads
> to the bus I/O routines and this is where the mei_bus_client ops will add the
> ME specific protocol (command and request id for the NFC block) on top of it.
> In practice, this is an additional header which handles a transport layer
> that's
> specific not only to the ME but to the NFC block of it. So each ME block can
> have its own protocol to send and receive technology specific payloads, that's
> what those ops implement.
> That's why I think that those ops should not be defined by the drivers/nfc/
> code
> and in fact should be opaque to it.
I think I'm still confused. What I read in your description is that unlike
other subsystems that have a common bus implementation that is hooked into
by two kinds of drivers (bus drivers that provide devices like a USB host
controller, and device drivers that use those devices), you have three
components that can be mixed independently: the bus (based on which
PCI device you have), the transport and the endpoint device. Is that
correct?
If so, how do you know which transport to use?
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [char-misc-next 03/11] mei: bus: Initial implementation for I/O routines
Hi Arnd,
On Mon, Feb 11, 2013 at 11:52:42AM +, Arnd Bergmann wrote:
> On Thursday 07 February 2013, Samuel Ortiz wrote:
> > On Thu, Feb 07, 2013 at 10:34:44PM +, Arnd Bergmann wrote:
> > > On Thursday 07 February 2013, Tomas Winkler wrote:
> > > > +
> > > > +struct mei_bus_ops {
> > > > + int (*send)(struct mei_bus_client *client, u8 *buf, size_t
> > > > length);
> > > > + int (*recv)(struct mei_bus_client *client, u8 *buf, size_t
> > > > length);
> > > > +};
> > > > +
> > >
> > > Can you have more than one set of mei_bus_ops in a driver?
> > You can have at most one mei_bus_ops per mei_bus_client.
> >
> > > If not, how about adding the callbacks to the mei_bus_driver structure
> > > directly as a simplification?
> > I can add the ops directly to the mei_bus_client structure, yes.
>
> I looked at the new version, and it's not what I assumed it would be.
> I thought the operations were specific to a client driver and should
> be part of the /mei_bus_driver/ structure, not the /mei_bus_client/.
The ops should be part of mei_bus_client as they're specific to the MEI
protocol for a given IP block on the ME. You need to have MEI and HECI
knowledge to implement those ops and drivers (defining their mei_bus_driver
structure) should not have that kind of knowledge but rather focus on the
technology they're driving.
If we take the NFC example again, the drivers/nfc/ code will send NFC payloads
to the bus I/O routines and this is where the mei_bus_client ops will add the
ME specific protocol (command and request id for the NFC block) on top of it.
In practice, this is an additional header which handles a transport layer that's
specific not only to the ME but to the NFC block of it. So each ME block can
have its own protocol to send and receive technology specific payloads, that's
what those ops implement.
That's why I think that those ops should not be defined by the drivers/nfc/ code
and in fact should be opaque to it.
> Did I misunderstand what these functions do, or did you misunderstand
> what I was asking for?
Probably both. I really thought you were looking for a structure cleanup by
directly putting the ops into the mei_bus_client structure.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [char-misc-next 03/11] mei: bus: Initial implementation for I/O routines
On Thursday 07 February 2013, Samuel Ortiz wrote:
> On Thu, Feb 07, 2013 at 10:34:44PM +, Arnd Bergmann wrote:
> > On Thursday 07 February 2013, Tomas Winkler wrote:
> > > +
> > > +struct mei_bus_ops {
> > > + int (*send)(struct mei_bus_client *client, u8 *buf, size_t
> > > length);
> > > + int (*recv)(struct mei_bus_client *client, u8 *buf, size_t
> > > length);
> > > +};
> > > +
> >
> > Can you have more than one set of mei_bus_ops in a driver?
> You can have at most one mei_bus_ops per mei_bus_client.
>
> > If not, how about adding the callbacks to the mei_bus_driver structure
> > directly as a simplification?
> I can add the ops directly to the mei_bus_client structure, yes.
I looked at the new version, and it's not what I assumed it would be.
I thought the operations were specific to a client driver and should
be part of the /mei_bus_driver/ structure, not the /mei_bus_client/.
Did I misunderstand what these functions do, or did you misunderstand
what I was asking for?
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [char-misc-next 03/11] mei: bus: Initial implementation for I/O routines
On Thursday 07 February 2013, Samuel Ortiz wrote:
On Thu, Feb 07, 2013 at 10:34:44PM +, Arnd Bergmann wrote:
On Thursday 07 February 2013, Tomas Winkler wrote:
+
+struct mei_bus_ops {
+ int (*send)(struct mei_bus_client *client, u8 *buf, size_t
length);
+ int (*recv)(struct mei_bus_client *client, u8 *buf, size_t
length);
+};
+
Can you have more than one set of mei_bus_ops in a driver?
You can have at most one mei_bus_ops per mei_bus_client.
If not, how about adding the callbacks to the mei_bus_driver structure
directly as a simplification?
I can add the ops directly to the mei_bus_client structure, yes.
I looked at the new version, and it's not what I assumed it would be.
I thought the operations were specific to a client driver and should
be part of the /mei_bus_driver/ structure, not the /mei_bus_client/.
Did I misunderstand what these functions do, or did you misunderstand
what I was asking for?
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [char-misc-next 03/11] mei: bus: Initial implementation for I/O routines
Hi Arnd,
On Mon, Feb 11, 2013 at 11:52:42AM +, Arnd Bergmann wrote:
On Thursday 07 February 2013, Samuel Ortiz wrote:
On Thu, Feb 07, 2013 at 10:34:44PM +, Arnd Bergmann wrote:
On Thursday 07 February 2013, Tomas Winkler wrote:
+
+struct mei_bus_ops {
+ int (*send)(struct mei_bus_client *client, u8 *buf, size_t
length);
+ int (*recv)(struct mei_bus_client *client, u8 *buf, size_t
length);
+};
+
Can you have more than one set of mei_bus_ops in a driver?
You can have at most one mei_bus_ops per mei_bus_client.
If not, how about adding the callbacks to the mei_bus_driver structure
directly as a simplification?
I can add the ops directly to the mei_bus_client structure, yes.
I looked at the new version, and it's not what I assumed it would be.
I thought the operations were specific to a client driver and should
be part of the /mei_bus_driver/ structure, not the /mei_bus_client/.
The ops should be part of mei_bus_client as they're specific to the MEI
protocol for a given IP block on the ME. You need to have MEI and HECI
knowledge to implement those ops and drivers (defining their mei_bus_driver
structure) should not have that kind of knowledge but rather focus on the
technology they're driving.
If we take the NFC example again, the drivers/nfc/ code will send NFC payloads
to the bus I/O routines and this is where the mei_bus_client ops will add the
ME specific protocol (command and request id for the NFC block) on top of it.
In practice, this is an additional header which handles a transport layer that's
specific not only to the ME but to the NFC block of it. So each ME block can
have its own protocol to send and receive technology specific payloads, that's
what those ops implement.
That's why I think that those ops should not be defined by the drivers/nfc/ code
and in fact should be opaque to it.
Did I misunderstand what these functions do, or did you misunderstand
what I was asking for?
Probably both. I really thought you were looking for a structure cleanup by
directly putting the ops into the mei_bus_client structure.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [char-misc-next 03/11] mei: bus: Initial implementation for I/O routines
On Monday 11 February 2013, Samuel Ortiz wrote:
On Mon, Feb 11, 2013 at 11:52:42AM +, Arnd Bergmann wrote:
On Thursday 07 February 2013, Samuel Ortiz wrote:
On Thu, Feb 07, 2013 at 10:34:44PM +, Arnd Bergmann wrote:
On Thursday 07 February 2013, Tomas Winkler wrote:
+
+struct mei_bus_ops {
+ int (*send)(struct mei_bus_client *client, u8 *buf, size_t
length);
+ int (*recv)(struct mei_bus_client *client, u8 *buf, size_t
length);
+};
+
Can you have more than one set of mei_bus_ops in a driver?
You can have at most one mei_bus_ops per mei_bus_client.
If not, how about adding the callbacks to the mei_bus_driver structure
directly as a simplification?
I can add the ops directly to the mei_bus_client structure, yes.
I looked at the new version, and it's not what I assumed it would be.
I thought the operations were specific to a client driver and should
be part of the /mei_bus_driver/ structure, not the /mei_bus_client/.
The ops should be part of mei_bus_client as they're specific to the MEI
protocol for a given IP block on the ME. You need to have MEI and HECI
knowledge to implement those ops and drivers (defining their mei_bus_driver
structure) should not have that kind of knowledge but rather focus on the
technology they're driving.
If we take the NFC example again, the drivers/nfc/ code will send NFC payloads
to the bus I/O routines and this is where the mei_bus_client ops will add the
ME specific protocol (command and request id for the NFC block) on top of it.
In practice, this is an additional header which handles a transport layer
that's
specific not only to the ME but to the NFC block of it. So each ME block can
have its own protocol to send and receive technology specific payloads, that's
what those ops implement.
That's why I think that those ops should not be defined by the drivers/nfc/
code
and in fact should be opaque to it.
I think I'm still confused. What I read in your description is that unlike
other subsystems that have a common bus implementation that is hooked into
by two kinds of drivers (bus drivers that provide devices like a USB host
controller, and device drivers that use those devices), you have three
components that can be mixed independently: the bus (based on which
PCI device you have), the transport and the endpoint device. Is that
correct?
If so, how do you know which transport to use?
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [char-misc-next 03/11] mei: bus: Initial implementation for I/O routines
Hi Arnd,
On Mon, Feb 11, 2013 at 03:08:24PM +, Arnd Bergmann wrote:
On Monday 11 February 2013, Samuel Ortiz wrote:
On Mon, Feb 11, 2013 at 11:52:42AM +, Arnd Bergmann wrote:
On Thursday 07 February 2013, Samuel Ortiz wrote:
On Thu, Feb 07, 2013 at 10:34:44PM +, Arnd Bergmann wrote:
On Thursday 07 February 2013, Tomas Winkler wrote:
+
+struct mei_bus_ops {
+ int (*send)(struct mei_bus_client *client, u8 *buf, size_t
length);
+ int (*recv)(struct mei_bus_client *client, u8 *buf, size_t
length);
+};
+
Can you have more than one set of mei_bus_ops in a driver?
You can have at most one mei_bus_ops per mei_bus_client.
If not, how about adding the callbacks to the mei_bus_driver structure
directly as a simplification?
I can add the ops directly to the mei_bus_client structure, yes.
I looked at the new version, and it's not what I assumed it would be.
I thought the operations were specific to a client driver and should
be part of the /mei_bus_driver/ structure, not the /mei_bus_client/.
The ops should be part of mei_bus_client as they're specific to the MEI
protocol for a given IP block on the ME. You need to have MEI and HECI
knowledge to implement those ops and drivers (defining their mei_bus_driver
structure) should not have that kind of knowledge but rather focus on the
technology they're driving.
If we take the NFC example again, the drivers/nfc/ code will send NFC
payloads
to the bus I/O routines and this is where the mei_bus_client ops will add
the
ME specific protocol (command and request id for the NFC block) on top of
it.
In practice, this is an additional header which handles a transport layer
that's
specific not only to the ME but to the NFC block of it. So each ME block can
have its own protocol to send and receive technology specific payloads,
that's
what those ops implement.
That's why I think that those ops should not be defined by the drivers/nfc/
code
and in fact should be opaque to it.
I think I'm still confused.
It is confusing, and my explanations are probably not as good as they should
be.
What I read in your description is that unlike
other subsystems that have a common bus implementation that is hooked into
by two kinds of drivers (bus drivers that provide devices like a USB host
controller, and device drivers that use those devices), you have three
components that can be mixed independently: the bus (based on which
PCI device you have), the transport and the endpoint device. Is that
correct?
That's quite accurate, yes.
If so, how do you know which transport to use?
Through the mei_bus_client ops. Device drivers get a mei_bus_client pointer
from their probe routine and the ops pointers there (If any) are set by
whoever creates the device. In the NFC case mei/nfc.c does that and implements
the NFC specific transport code for this technology. mei/nfc.c is also the
part of the code that actually adds the device to the bus.
So when a device driver wants e.g. to send its payload through the MEI bus, it
calls mei_bus_send() which takes the device driver mei_bus client pointer as
its first argument.
Then the payload may go through mei_bus_client-send() first which will
eventually
physically sent the newly built frame through mei_send(). Some ME blocks don't
require any
additional transport layer and in that case the device driver payload will go
straight to mei_send() since the mei_bus_client ops will be NULL.
Does that make more sense now ?
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [char-misc-next 03/11] mei: bus: Initial implementation for I/O routines
On Monday 11 February 2013 16:48:12 Samuel Ortiz wrote: If so, how do you know which transport to use? Through the mei_bus_client ops. Device drivers get a mei_bus_client pointer from their probe routine and the ops pointers there (If any) are set by whoever creates the device. In the NFC case mei/nfc.c does that and implements the NFC specific transport code for this technology. mei/nfc.c is also the part of the code that actually adds the device to the bus. Ok. So when a device driver wants e.g. to send its payload through the MEI bus, it calls mei_bus_send() which takes the device driver mei_bus client pointer as its first argument. Then the payload may go through mei_bus_client-send() first which will eventually physically sent the newly built frame through mei_send(). Some ME blocks don't require any additional transport layer and in that case the device driver payload will go straight to mei_send() since the mei_bus_client ops will be NULL. Does that make more sense now ? Yes, so it's not actually as complicated as I thought, because the operations are already known by the bus driver (in the normal sense of that word, meaning the driver that creates the device not the one driving it) at the time when the device is created. In that case, please ignore my original comment and put the struct mei_bus_ops (mei_transport_ops?) back, ideally as a const member of the struct mei_bus_device (to be called mei_device then), so you can declare the structure statically and constant in the driver that has the functions. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [char-misc-next 03/11] mei: bus: Initial implementation for I/O routines
Hi Arnd,
On Thu, Feb 07, 2013 at 10:34:44PM +, Arnd Bergmann wrote:
> On Thursday 07 February 2013, Tomas Winkler wrote:
> > +
> > +struct mei_bus_ops {
> > + int (*send)(struct mei_bus_client *client, u8 *buf, size_t length);
> > + int (*recv)(struct mei_bus_client *client, u8 *buf, size_t length);
> > +};
> > +
>
> Can you have more than one set of mei_bus_ops in a driver?
You can have at most one mei_bus_ops per mei_bus_client.
> If not, how about adding the callbacks to the mei_bus_driver structure
> directly as a simplification?
I can add the ops directly to the mei_bus_client structure, yes.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [char-misc-next 03/11] mei: bus: Initial implementation for I/O routines
On Thursday 07 February 2013, Tomas Winkler wrote:
> +
> +struct mei_bus_ops {
> + int (*send)(struct mei_bus_client *client, u8 *buf, size_t length);
> + int (*recv)(struct mei_bus_client *client, u8 *buf, size_t length);
> +};
> +
Can you have more than one set of mei_bus_ops in a driver? If not,
how about adding the callbacks to the mei_bus_driver structure
directly as a simplification? Never mind if that doesn't work for
some obvious reason I missed.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [char-misc-next 03/11] mei: bus: Initial implementation for I/O routines
On Thursday 07 February 2013, Tomas Winkler wrote:
+
+struct mei_bus_ops {
+ int (*send)(struct mei_bus_client *client, u8 *buf, size_t length);
+ int (*recv)(struct mei_bus_client *client, u8 *buf, size_t length);
+};
+
Can you have more than one set of mei_bus_ops in a driver? If not,
how about adding the callbacks to the mei_bus_driver structure
directly as a simplification? Never mind if that doesn't work for
some obvious reason I missed.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [char-misc-next 03/11] mei: bus: Initial implementation for I/O routines
Hi Arnd,
On Thu, Feb 07, 2013 at 10:34:44PM +, Arnd Bergmann wrote:
On Thursday 07 February 2013, Tomas Winkler wrote:
+
+struct mei_bus_ops {
+ int (*send)(struct mei_bus_client *client, u8 *buf, size_t length);
+ int (*recv)(struct mei_bus_client *client, u8 *buf, size_t length);
+};
+
Can you have more than one set of mei_bus_ops in a driver?
You can have at most one mei_bus_ops per mei_bus_client.
If not, how about adding the callbacks to the mei_bus_driver structure
directly as a simplification?
I can add the ops directly to the mei_bus_client structure, yes.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
