lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 22 Apr 2011 20:20:23 +0200
From:	Jean Delvare <khali@...ux-fr.org>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	Seth Heasley <seth.heasley@...el.com>, linux-i2c@...r.kernel.org,
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.39-rc3] i2c-i801: SMBus patch for Intel Panther 
 Point DeviceIDs

On Fri, 22 Apr 2011 09:52:59 -0700, Jesse Barnes wrote:
> On Fri, 22 Apr 2011 18:44:49 +0200
> Jean Delvare <khali@...ux-fr.org> wrote:
> 
> > Hi Seth,
> > 
> > On Wed, 20 Apr 2011 11:33:39 -0700, Seth Heasley wrote:
> > > This patch adds the SMBus controller DeviceID for the Intel Panther Point PCH.
> > 
> > With each new chip, we have to add the SMBus device ID to pci_ids.h,
> > then wait for Jesse to merge that, and only then I can apply the
> > changes to i2c-i801.c. This approach slows things down needlessly.
> > 
> > It isn't mandatory to add IDs to pci_ids.h when an ID is only used
> > locally in a device driver. So what I would like to propose is that we
> > move all PCI_DEVICE_ID_INTEL_*_SMBUS declarations from pci_ids.h to
> > i2c-i801.c now. Then you can resubmit your Panther Point patches, and
> > the pci and i2c parts will be independent, so Jesse and myself don't
> > depend on each other to apply them.
> > 
> > What do you think? Jesse, any objection?
> > 
> > Seth, if you agree, I can take care of the move, or you can send a
> > patch doing that, whatever you prefer.
> 
> Yeah, that makes sense.  I'd be happy to take a patch to pull the
> defines out of pci_ids.h and push them into the x86 irq.c and your i2c
> code.

I really only had i2c in mind. For irq it's a little different because
it relates to devices which are kind of generic and the IDs could be
(and, I think, are) used in more than one place (such as quirks.c) for
at least some of these devices.

-- 
Jean Delvare
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ