lkml.org 
[lkml]   [2014]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 0/2] managed token devres interfaces
Hi Alan,

Em Thu, 10 Apr 2014 12:04:35 +0100
One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> escreveu:

> > >> - Construct string with (dev is struct em28xx *dev)
> > >> format: "tuner:%s-%s-%d"
> > >> with the following:
> > >> dev_name(&dev->udev->dev)
> > >> dev->udev->bus->bus_name
> > >> dev->tuner_addr
>
> What guarantees this won't get confused by hot plugging and re-use of the
> bus slot ?

Good point. Yes, this should be addressed.

> I'm also not sure I understand why you can't have a shared parent device
> and simply attach the resources to that. This sounds like a problem mfd
> already solved ?

There are some devices that have lots of different functions spread
out on several subsystems.

For example, some devices provide standard USB Audio Class, handled by
snd-usb-audio for the audio stream, while the video stream is handled
via a separate driver, like some em28xx devices.

There are even more complex devices that provide 3G modem, storage
and digital TV, whose USB ID changes when either the 3G modem starts
or when the digital TV firmware is loaded.

So, we need to find a way to lock some hardware resources among
different subsystems that don't share anything in common. Not sure if
mfd has the same type of problem of a non-mfd driver using another
function of the same device that has some shared hardware resources
between the separate functions, and, if so, how they solved it.

Regards,
Mauro


\
 
 \ /
  Last update: 2014-04-10 14:01    [W:1.269 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site