Re: [PULL -tip] x86: replacing mp_config_X with mpc_X

[Ingo Molnar <mingo@elte.hu>]

* Jaswinder Singh Rajput <jaswinder@infradead.org> wrote:

> -struct mp_config_ioapic {
> -	unsigned long mp_apicaddr;
> -	unsigned int mp_apicid;
> -	unsigned char mp_type;
> -	unsigned char mp_apicver;
> -	unsigned char mp_flags;
> -};
> -
> -struct mp_config_intsrc {
> -	unsigned int mp_dstapic;
> -	unsigned char mp_type;
> -	unsigned char mp_irqtype;
> -	unsigned short mp_irqflag;
> -	unsigned char mp_srcbus;
> -	unsigned char mp_srcbusirq;
> -	unsigned char mp_dstirq;
> -};

So you replaced that with mpc_ioapic and mpc_intsrc uses:

 struct mpc_ioapic {
         unsigned char type;
         unsigned char apicid;
         unsigned char apicver;
         unsigned char flags;
         unsigned int apicaddr;
 };

 struct mpc_intsrc {
         unsigned char type;
         unsigned char irqtype;
         unsigned short irqflag;
         unsigned char srcbus;
         unsigned char srcbusirq;
         unsigned char dstapic;
         unsigned char dstirq;
 };

And removed the mp_config_ioapic and mp_config_intsrc types.

The mp_config_ioapic and mp_config_intsrc types are kernel-internal, while 
mpc_ioapic and mpc_intsrc is an MP Specification type - the lowlevel 
structure of these tables as provided in RAM or ROM by the BIOS.

Here's the potential problems that need to be thought through:

- the biggest potential problem is that apicaddr is 32-bit wide while 
  mp_apicaddr is 64-bit wide, on the 64-bit kernel. Can an apic address be 
  above 4 GB, in an mptable? I dont think it can be.

- another problem could be that dstapic are all 1-byte entities - while in
  the in-kernel version (mp_apicid and mp_dstapic) they are 32 bit. The 
  ACPI code fills in the tables too so maybe there it can be wider than 8 
  bits?

I've Cc:-ed a few more folks.

The cleanup potential is significant: we can get rid of all the type 
mixing that we do (assign_to_mp_irq(), assign_to_mpc_intsrc() can go away, 
etc.) and can standardize the code.

	Ingo