On Fri, 2005-04-08 at 15:07 -0500, Kylene Jo Hall wrote:
> Basically, what I need to figure out is how to solve both issues
> simultaneously. I need to not register a pci_driver as I would be
> taking over an ID that is not unique to my device as well as get the
> hotplugging correct (which i don
On Tue, 2005-04-05 at 11:14 -0500, Kylene Jo Hall wrote:
> On Thu, 2005-03-24 at 13:33 -0800, Greg KH wrote:
> > On Thu, Mar 24, 2005 at 04:04:25PM -0500, Jeff Garzik wrote:
> > > Greg KH wrote:
> > > >On Tue, Mar 22, 2005 at 09:02:24PM -0500, Jeff Garzik wrote:
> > > >
> > > >>Kylene Hall wrote:
>
On Thu, 2005-03-24 at 13:33 -0800, Greg KH wrote:
> On Thu, Mar 24, 2005 at 04:04:25PM -0500, Jeff Garzik wrote:
> > Greg KH wrote:
> > >On Tue, Mar 22, 2005 at 09:02:24PM -0500, Jeff Garzik wrote:
> > >
> > >>Kylene Hall wrote:
> > >>
> > what is the purpose of this pci_dev_get/put? attemptin
On Thu, Mar 24, 2005 at 04:04:25PM -0500, Jeff Garzik wrote:
> Greg KH wrote:
> >On Tue, Mar 22, 2005 at 09:02:24PM -0500, Jeff Garzik wrote:
> >
> >>Kylene Hall wrote:
> >>
> what is the purpose of this pci_dev_get/put? attempting to prevent
> hotplug or
> something?
> >>>
> >>>
> >>
Greg KH wrote:
On Tue, Mar 22, 2005 at 09:02:24PM -0500, Jeff Garzik wrote:
Kylene Hall wrote:
what is the purpose of this pci_dev_get/put? attempting to prevent
hotplug or
something?
Seems that since there is a refernce to the device in the chip structure
and I am making the file private data
On Tue, Mar 22, 2005 at 09:02:24PM -0500, Jeff Garzik wrote:
> Kylene Hall wrote:
> >>what is the purpose of this pci_dev_get/put? attempting to prevent
> >>hotplug or
> >>something?
> >
> >
> >Seems that since there is a refernce to the device in the chip structure
> >and I am making the file p
Kylene Hall wrote:
what is the purpose of this pci_dev_get/put? attempting to prevent hotplug or
something?
Seems that since there is a refernce to the device in the chip structure
and I am making the file private data pointer point to that chip structure
this is another reference that must be
The patch at the bottom addresses a number of the concerns raised in this
email along with a couple of other comments which this generated regarding
not needing __force and the need for a MAINTAINERS entry.
Signed-off-by: Kylene Hall <[EMAIL PROTECTED]>
On Wed, 9 Mar 2005, Jeff Garzik wrote:
>
Thanks for the helpful comments I am working on a patch to fix your
concerns but I have a couple of questions.
On Wed, 2005-03-09 at 22:51 -0500, Jeff Garzik wrote:
> > + down(&chip->timer_manipulation_mutex);
> > + chip->time_expired = 0;
> > + init_timer(&chip->device_timer);
> > + c
On Thursday 10 March 2005 02:42, Greg KH wrote:
> [PATCH] Add TPM hardware enablement driver
> +static ssize_t tpm_transmit(struct tpm_chip *chip, const char *buf,
> + size_t bufsiz)
> +{
> + u32 count;
> + __be32 *native_size;
> +
> + native_size = (__force _
On Thu, 10 Mar 2005 09:35:36 -0800, Nish Aravamudan
<[EMAIL PROTECTED]> wrote:
> On Wed, 9 Mar 2005 16:42:01 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> > ChangeSet 1.2035, 2005/03/09 10:12:19-08:00, [EMAIL PROTECTED]
> >
> > [PATCH] Add TPM hardware enablement driver
>
>
>
> > +void tpm_time_ex
On Wed, 9 Mar 2005 16:42:01 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> ChangeSet 1.2035, 2005/03/09 10:12:19-08:00, [EMAIL PROTECTED]
>
> [PATCH] Add TPM hardware enablement driver
> +void tpm_time_expired(unsigned long ptr)
> +{
> + int *exp = (int *) ptr;
> + *exp = 1;
> +}
> +
>
Greg KH wrote:
diff -Nru a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/char/tpm/tpm.c 2005-03-09 16:40:26 -08:00
@@ -0,0 +1,697 @@
+/*
+ * Copyright (C) 2004 IBM Corporation
+ *
+ * Authors:
+ * Leendert van Doorn <[EMAIL PROTECTED]>
+ * Da
13 matches
Mail list logo
