RE: [patch] input: Fix CLOCK_TICK_RATE usage ... [8/13]

David Mosberger (davidm@napali.hpl.hp.com)
Wed, 25 Jun 2003 11:49:26 -0700


>>>>> On Wed, 25 Jun 2003 18:56:43 +0100, "Riley Williams" <Riley@Williams.Name> said:

>> AFAIK, the drivers you're talking about all depend on there
>> being an 8259-style PIT. As such, they depend on the 8259
>> and are not generic. This dependency should be made explicit.

Riley> In that case, ALL of the drivers in question need to be moved
Riley> under the linux/arch tree. Very few are currently there.

Not at all. It's completely standard to have drivers in
linux/drivers/ which may never be enabled for certain platforms. Or
what's the last time an x86 PC used an Sun SBUS driver?

>>> 2. According to the IA64 people, those GENERIC drivers
>>> are apparently irrelevant for that architecture, so
>>> making the CORRECT change of replacing those magic
>>> numbers in the GENERIC drivers with the CLOCK_TICK_RATE
>>> value will make no difference to IA64.

>> That's not precise: _some_ ia64 machines do have legacy hardware
>> and those should be able to use 8259-dependent drivers if they
>> choose to do so.

Riley> My comment as quoted above is a summary of the comments made by
Riley> the IA64 developers in this thread. I know ZILCH about the IA64
Riley> architecture because, as with the ALPHA architecture, I've never
Riley> even seen one. I thus have to assume that comments made by the
Riley> IA64 maintainers are accurate.

You seem to fail to realize that I _am_ the ia64 linux tree maintainer.
What does it take for you to believe me?

>> Moreover, the current drivers would compile just fine on ia64,
>> even though they could not possibly work correctly with the
>> current use of CLOCK_TICK_RATE. With a separate header file
>> (and a config option), these dependencies would be made
>> explicit and that would improve overall cleanliness.

Riley> I agree that the dependencies need to be made explicit.

Good.

Riley> However, I'm not convinced that a separate header file is
Riley> justified, much less needed.

timex.h definitely is the wrong place. If you know of a better place
(other than <asm/pit.h>), I'm all ears.

>> In other words, I still think the right way to go about this
>> is to have <asm/pit.h>. On x86, this could be:
>>
>> --
>> #include <asm/timex.h>
>>
>> #define PIT_FREQ CLOCK_TICK_RATE
>> #define PIT_LATCH ((PIT_FREQ + HZ/2) / HZ)
>> --
>>
>> If you insist, you could even put this in asm-generic, though
>> personally I don't think that's terribly elegant.

Riley> The important details are...

Riley> 1. The relevant values are in a known header file.

Riley> 2. That header file is referenced and the values therein
Riley> are used rather than just using magic numbers.

I have no problem with that.

Riley> Personally, I have no problem with which header files are used.
Riley> What matters is that inclusion of a specified header file always
Riley> defines the relevant values.

Can we then agree to just create <asm/pit.h> and be done with it?

>> On ia64, <asm/pit.h> could be:

>> #ifdef CONFIG_PIT
>> # define PIT_FREQ 1193182
>> # define PIT_LATCH ((PIT_FREQ + HZ/2) / HZ)
>> #endif

Riley> You would then need to ensure that if CONFIG_PIT was not defined,
Riley> no reference was ever made to either PIT_FREQ or PIT_LATCH which
Riley> can easily become ugly code that the maintainers won't touch.

Thanks to the new Kbuild, it's very easy: just add a "depends on PIT"
for drivers that depend on the PIT (I think that's primarily ftape and
the drivers/input/misc/{pc,98}spkr.c.

--david
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/