Pete Zaitcev wrote:
> > i2c is only in our stuff because the i2c core is not in the standard kernel
> > yet. As soon as it is, I will make cobalt_i2c* go away.
>
> I am puzzled by this comment. Did you look into drivers/i2c/?
> It certainly is a part of a stock kernel. The main user is
> the
On Fri, 1 Jun 2001, Pete Zaitcev wrote:
> > But, each time a user cats this proc file, the user is banging the
> > hardware. What happens when a malicious user forks off 100 processes to
> > continually cat this file? :)
>
> Nothing good, probably. Same story as /proc/apm, which only
> hits
> But, each time a user cats this proc file, the user is banging the
> hardware. What happens when a malicious user forks off 100 processes to
> continually cat this file? :)
Nothing good, probably. Same story as /proc/apm, which only
hits BIOS instead (and it's debateable what is better).
>
> From: Tim Hockin <[EMAIL PROTECTED]>
> Date: Thu, 31 May 2001 23:57:48 -0700 (PDT)
> > i2c framework is not used, I wonder why. Someone thought that
> > it was too heavy perhaps? If so, I disagree.
>
> i2c is only in our stuff because the i2c core is not in the standard kernel
> yet. As soon
Tim Hockin wrote:
> +int __init
> +cobalt_acpi_init(void)
> +{
> + int err, reg;
> + u16 addr;
> + unsigned long flags;
> +
> + if (cobt_is_5k()) {
> + /* setup osb4 i/o regions */
> + if ((reg = get_reg(OSB4_INDEX_PORT, OSB4_DATA_PORT, 0x20)))
General comments:
* Code looks really clean. Nice work.
* Use module_init/exit. I know, I know, you heard it before :)
* I dunno if Linus will take it as-is because he has been threatening to
stop taking PCI drives that use old-style PCI init for no good reason.
(he even made me change a
> > Off-hand I see old style initialization. Is it right for new driver?
>
> the old-style init is because it is an old driver. I want to do a full-on
> rework, but haven't had the time.
New-style init by itself shouldn't be hard to do, independent of a full
re-work...
> > 2. Spaces and tabs
> Looks interesting. Seemingly literate use of spinlocks.
thanks - I gave it lots of thought.
> Off-hand I see old style initialization. Is it right for new driver?
the old-style init is because it is an old driver. I want to do a full-on
rework, but haven't had the time.
> i2c framework is
Looks interesting. Seemingly literate use of spinlocks.
thanks - I gave it lots of thought.
Off-hand I see old style initialization. Is it right for new driver?
the old-style init is because it is an old driver. I want to do a full-on
rework, but haven't had the time.
i2c framework is not
Off-hand I see old style initialization. Is it right for new driver?
the old-style init is because it is an old driver. I want to do a full-on
rework, but haven't had the time.
New-style init by itself shouldn't be hard to do, independent of a full
re-work...
2. Spaces and tabs are
General comments:
* Code looks really clean. Nice work.
* Use module_init/exit. I know, I know, you heard it before :)
* I dunno if Linus will take it as-is because he has been threatening to
stop taking PCI drives that use old-style PCI init for no good reason.
(he even made me change a
Tim Hockin wrote:
+int __init
+cobalt_acpi_init(void)
+{
+ int err, reg;
+ u16 addr;
+ unsigned long flags;
+
+ if (cobt_is_5k()) {
+ /* setup osb4 i/o regions */
+ if ((reg = get_reg(OSB4_INDEX_PORT, OSB4_DATA_PORT, 0x20)))
+
From: Tim Hockin [EMAIL PROTECTED]
Date: Thu, 31 May 2001 23:57:48 -0700 (PDT)
i2c framework is not used, I wonder why. Someone thought that
it was too heavy perhaps? If so, I disagree.
i2c is only in our stuff because the i2c core is not in the standard kernel
yet. As soon as it is,
But, each time a user cats this proc file, the user is banging the
hardware. What happens when a malicious user forks off 100 processes to
continually cat this file? :)
Nothing good, probably. Same story as /proc/apm, which only
hits BIOS instead (and it's debateable what is better).
On Fri, 1 Jun 2001, Pete Zaitcev wrote:
But, each time a user cats this proc file, the user is banging the
hardware. What happens when a malicious user forks off 100 processes to
continually cat this file? :)
Nothing good, probably. Same story as /proc/apm, which only
hits BIOS
Pete Zaitcev wrote:
i2c is only in our stuff because the i2c core is not in the standard kernel
yet. As soon as it is, I will make cobalt_i2c* go away.
I am puzzled by this comment. Did you look into drivers/i2c/?
It certainly is a part of a stock kernel. The main user is
the V4L, in
> Aattached is a (large, but self contained) patch for Cobalt Networks suport
> for x86 systems (RaQ3, RaQ4, Qube3, RaQXTR). Please let me know if there
> is anything that would prevent this from general inclusion in the next
> release.
Looks interesting. Seemingly literate use of spinlocks.
Aattached is a (large, but self contained) patch for Cobalt Networks suport
for x86 systems (RaQ3, RaQ4, Qube3, RaQXTR). Please let me know if there
is anything that would prevent this from general inclusion in the next
release.
Looks interesting. Seemingly literate use of spinlocks.
18 matches
Mail list logo
