On Mon, May 20, 2013 at 03:19:38PM -0700, David Daney wrote:
> From: David Daney
>
> CAVIUM_OCTEON_SOC most place we used to use CPU_CAVIUM_OCTEON. This
> allows us to CPU_CAVIUM_OCTEON in places where we have no OCTEON SOC.
>
> Remove CAVIUM_OCTEON_SIMULATOR as it doesn't really do anything, w
On Sat, Dec 22, 2012 at 12:21:15PM +0100, Federico Vaga wrote:
> > I'm cautious about adding operational interfaces to sysfs because it
> > can be quite difficult to get the locking right. To begin with it
> > splits up a single interface into multiple files, any of which can
> > be held open by a
On Mon, Sep 17, 2012 at 01:28:50PM -0700, Greg KH wrote:
> On Mon, Sep 17, 2012 at 12:40:16PM -0700, Tejun Heo wrote:
> > On Fri, Sep 14, 2012 at 03:50:40PM -0700, Colin Cross wrote:
> > > This patch set fixes a reproducible crash I'm seeing on a 3.4.10
> > > kern
On Mon, Sep 17, 2012 at 12:40:16PM -0700, Tejun Heo wrote:
> On Fri, Sep 14, 2012 at 03:50:40PM -0700, Colin Cross wrote:
> > This patch set fixes a reproducible crash I'm seeing on a 3.4.10
> > kernel. flush_kthread_worker (which is different from
> > flush_kthread_work) is initializing a kthread
On Fri, Jan 13, 2012 at 10:07:19AM +0100, Guennadi Liakhovetski wrote:
> I didn't find this patch either in "next" or in Greg's "driver-core"
> trees, so, couldn't generate a patch and had to comment here:
It's in Linus's tree now.
> > +/**
> > + * module_driver() - Helper macro for drivers that
On Tue, Nov 22, 2011 at 12:56:32PM +0100, Alessandro Rubini wrote:
> > I have Acks on some of the driver patches and no comments on the
> > rest. I've been circulating these for some time, so if you're
> > happy to pull those driver patches via your tree, please go ahead.
>
> Sure I have no probl
On Wed, Nov 16, 2011 at 10:13:35AM +0100, Lars-Peter Clausen wrote:
> This patch generalizes the module_platform_driver macro and introduces a new
> module_driver macro. The module_driver macro takes a driver name, a register
> and a unregister function for this driver type. Using these it construc
On Wed, Nov 16, 2011 at 10:13:31AM -0700, Grant Likely wrote:
> On Wed, Nov 16, 2011 at 9:37 AM, Greg KH wrote:
> > On Wed, Nov 16, 2011 at 05:36:18PM +0100, Jean Delvare wrote:
> >> On Wed, 16 Nov 2011 08:02:06 -0800, Greg KH wrote:
> >> > On Wed, Nov 16, 2011 a
On Wed, Nov 16, 2011 at 05:36:18PM +0100, Jean Delvare wrote:
> On Wed, 16 Nov 2011 08:02:06 -0800, Greg KH wrote:
> > On Wed, Nov 16, 2011 at 10:13:34AM +0100, Lars-Peter Clausen wrote:
> > > Grant Likely recently introduced the module_platform_driver macro which
> >
On Wed, Nov 16, 2011 at 10:13:34AM +0100, Lars-Peter Clausen wrote:
> Grant Likely recently introduced the module_platform_driver macro which can be
> used to eliminate a few lines on boilerplate code in platform driver modules.
> The same approach can be used to do the same for other bus type driv
On Fri, Sep 02, 2011 at 11:24:04AM -0700, Stephen Warren wrote:
> Jean Delvare wrote at Friday, September 02, 2011 3:25 AM:
> > Hi Jonathan,
> >
> > On Fri, 02 Sep 2011 10:19:24 +0100, Jonathan Cameron wrote:
> > > On 09/02/11 07:56, Jean Delvare wrote:
> > > > Stephen,
> > > >
> > > > Can you ple
On Wed, Apr 06, 2011 at 09:59:02PM +0300, Felipe Balbi wrote:
> Hi,
>
> On Wed, Apr 06, 2011 at 08:47:34PM +0200, Samuel Ortiz wrote:
> > > > > What is a "MFD cell pointer" and why is it needed in struct device?
> > > > An MFD cell is an MFD instantiated device.
> > > > MFD (Multi Function Device)
On Wed, Apr 06, 2011 at 11:25:57AM -0700, Andres Salomon wrote:
> > > We've been faced with the problem of being able to pass both MFD
> > > related data and a platform_data pointer to some of those drivers.
> > > Squeezing the MFD bits in the sub driver platform_data pointer
> > > doesn't work for
On Wed, Apr 06, 2011 at 07:05:38PM +0200, Samuel Ortiz wrote:
> Hi Greg,
>
> On Wed, Apr 06, 2011 at 08:58:05AM -0700, Greg KH wrote:
> > On Wed, Apr 06, 2011 at 05:23:23PM +0200, Samuel Ortiz wrote:
> > > --- a/include/linux/device.h
> > > +++ b/include/li
On Wed, Apr 06, 2011 at 05:23:23PM +0200, Samuel Ortiz wrote:
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -33,6 +33,7 @@ struct class;
> struct subsys_private;
> struct bus_type;
> struct device_node;
> +struct mfd_cell;
>
> struct bus_attribute {
> struct attribu
On Wed, Nov 17, 2010 at 09:11:30AM -0700, Grant Likely wrote:
> Also, any dependency tracking must work across bus_types. It is not
> sufficient to only handle the platform_devices use-case. All bus
> types have this need.
Agreed.
> I see a few potential approaches.
>
> Option 1: Add a list of
On Tue, Oct 26, 2010 at 02:13:52PM +0100, Alan Cox wrote:
> From: Russ Gorby
>
> Prototype driver for the IFX6x60 series of SPI attached modems by Jim
> Stanley and Russ Gorby
>
> Signed-off-by: Russ Gorby
>
> [Some reworking and a major cleanup]
>
> Signed-off-by: Alan Cox
> ---
>
> drive
On Tue, Feb 09, 2010 at 09:36:44AM +0800, Feng Tang wrote:
> On Tue, 9 Feb 2010 08:26:35 +0800
> Grant Likely wrote:
>
> > On Mon, Feb 8, 2010 at 5:20 PM, Andrew Morton
> > wrote:
> > > On Mon, 8 Feb 2010 16:59:46 +0800
> > > Feng Tang wrote:
> > >
> > >> Hi All,
> > >>
> > >> Here is a driver
On Wed, Aug 19, 2009 at 02:04:18AM +0400, Anton Vorontsov wrote:
> This is needed to avoid ugly #ifdefs in drivers. Also update fsl_qe_udc
> driver so that now it doesn't define its own versions that cause build
> breakage when the generic stubs are used.
>
> Signed-off-by: Anton Vorontsov
As yo
On Sun, May 31, 2009 at 09:27:56PM +0200, Linus Walleij wrote:
> 2009/5/31 Baruch Siach :
>
> >> > + r = platform_get_resource(dev, IORESOURCE_MEM, 0);
> >> > + if (r == NULL) {
> >> > + ret = -ENODEV;
> >>
> >> -ENOENT
> >
> > A quick search in the drivers tree showed no
On Thu, Jan 10, 2008 at 05:48:43PM +0800, Dave Young wrote:
> The patches are done on my side, please help to check.
Along with all of the other comments from people, I have a few.
> This is the first one of the series about driver core changes.
> If this one is accepted and there's no other pr
On Mon, Jan 07, 2008 at 06:13:37PM +0100, Stefan Richter wrote:
> It's already in the driver core to the most part. It remains to be seen
> what is less complicated in the end: Transparent mutex-protected list
> accesses provided by driver core (requires the iterator), or all the
> necessary lock
On Tue, Jan 08, 2008 at 03:05:10PM +0800, Dave Young wrote:
> On Jan 8, 2008 1:20 AM, Greg KH <[EMAIL PROTECTED]> wrote:
> > On Mon, Jan 07, 2008 at 06:13:37PM +0100, Stefan Richter wrote:
> > > It's already in the driver core to the most part. It remains to be seen
&
On Mon, Jan 07, 2008 at 02:23:33PM +0100, Stefan Richter wrote:
> David Brownell wrote:
> > On Monday 07 January 2008, Greg KH wrote:
> >> Most of the non-driver core code should be converted to not use the
> >> lock in the class at all. They should use a local lock
On Mon, Jan 07, 2008 at 10:09:44AM +0800, Dave Young wrote:
>
> Thanks for your comment, I rewrite it for 2.6.24-rc7 as a all-in-one
> patch, please see following. Drop i2c maintainer and list in cc
> because there's no changes about i2c in this patch:
>
> Convert semaphore to mutex in struct cla
On Mon, Oct 15, 2007 at 04:28:09PM -0700, David Brownell wrote:
> > ug. Half of this patch seems to have got into Greg's tree, as
> > spi-convert-from-class_device-to-device-for-spi.patch.
>
> Greg was supposed to remove that partial/incomplete patch ...
> when he added it, I told him it was the
26 matches
Mail list logo
