[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <20140410083841.488f9c43@samsung.com>
Date: Thu, 10 Apr 2014 08:38:41 -0300
From: Mauro Carvalho Chehab <m.chehab@...sung.com>
To: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc: shuah.kh@...sung.com, Greg KH <gregkh@...uxfoundation.org>,
tj@...nel.org, rafael.j.wysocki@...el.com, linux@...ck-us.net,
toshi.kani@...com, linux-kernel@...r.kernel.org,
linux-media@...r.kernel.org, shuahkhan@...il.com
Subject: Re: [RFC PATCH 0/2] managed token devres interfaces
Hi Alan,
Em Thu, 10 Apr 2014 12:04:35 +0100
One Thousand Gnomes <gnomes@...rguk.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
--
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/
Powered by blists - more mailing lists