A patch for w83791d for 2.6 kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2/10/06, Greg KH <greg at kroah.com> wrote:
> On Fri, Feb 10, 2006 at 02:23:00PM -0800, Charles Spirakis wrote:
> > See below:
> >
> > On 2/10/06, Greg KH <greg at kroah.com> wrote:
> > > On Thu, Feb 09, 2006 at 01:34:42PM -0800, Charles Spirakis wrote:
> > > > All --
> > > >
> > > > Below is a patch to add w83791d support into the 2.6 kernel. This
> > > > patch was created off of the 2.6.15.3 base, but it should apply
> > > > cleanly on many earlier kernels (been tried on 2.6.14.3 and 2.6.15.1).
> > > >
> > > > I've tried this on the system I have available here and it appears to work.
> > > >
> > > > Thanks!
> > > >
> > > > -- charles
> > > >
> > > >
> > > > diff -urpN linux-2.6.15.3/Documentation/hwmon/w83791d
> > > > linux-2.6.15.3-w83791d/Documentation/hwmon/w83791d
> > > > --- linux-2.6.15.3/Documentation/hwmon/w83791d  1969-12-31
> > > > 16:00:00.000000000 -0800
> > >
> > > It looks like your email client wrapped the lines of the patch, and ate
> > > all of the tabs for breakfast and spit them back out as spaces :(
> > >
> > > Care to fix up your mailer problems and try again?
> > >
> >
> > Hmm... I'm not sure how to fix the mailer problem (just used gmail and
> > cut/paste'd into the text box).
>
> Oh that will never work :)
>
> > If I sent the patch as an attachment instead, would the lm_sensor
> > mailer handle it properly? Would it help to tar/compress it? Or would
> > that make it worse?
>
> No compression please, try attaching it as a plain text file.  The
> SubmittingPatches document has some text on how to do this properly.

Ok. I'll play around with this and see if I can send something to
myself that doesn't get butchered. I'll try to repost the patch when
I've discovered the secret...

>
> > >
> > > > +}
> > > > +
> > > > +struct w83791d_data {
> > > > +       struct i2c_client client;
> > > > +       struct class_device *class_dev;
> > > > +       struct semaphore lock;
> > >
> > > Perhaps a mutex instead?
> >
> > In looking at the code, that particular lock isn't needed (the
> > update_lock can be used for everything) so I'll remove it. However, as
> > a general question, should the update_lock be changed? It is
> > initialized via init_MUTEX() ~line 1280, but is there more that is
> > needed? Is there a specific mutex type (struct mutex)? I don't
> > remember seeing anything like that, but perhaps I missed it.
>
> It's brand new, came after 2.6.15.

OK. I'll take a look.  I'm assuming since this is a post 2.6.15
feature, then that implies the patch will only work for post 2.6.15
kernels...

>
> > Or should the name be more reflective of the fact there is only one
> > owner of the lock allowed (aka update_mutex vs. update_lock)?
>
> Should not matter.
>
> thanks,
>
> greg k-h
>

Thanks for the feedback!




[Index of Archives]     [Linux Kernel]     [Linux Hardware Monitoring]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux