[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 02/21] acpi: Prevent GPL-only code from seeping into non-GPL binaries
>>> On 20.09.16 at 02:19, <boris.ostrovsky@xxxxxxxxxx> wrote: > --- a/tools/firmware/hvmloader/acpi/dsdt.asl > +++ /dev/null Please try to represent this as a move, not as a delete+create. > + Scope ( \_SB.PCI0 ) > + { > + Name ( BUFA, ResourceTemplate() { IRQ(Level, ActiveLow, Shared) { 5, > 10, 11 } } ) > + Name ( BUFB, Buffer() { 0x23, 0x00, 0x00, 0x18, 0x79, 0 } ) > + CreateWordField ( BUFB, 0x01, IRQV ) > + Device ( LNKA ) { > + Name ( _HID, EISAID("PNP0C0F") ) > + Name ( _UID, 1 ) > + Method ( _STA, 0 ) { > + If ( And(PIRA, 0x80) ) { > + Return ( 0x09 ) > + } > + Else { > + Return ( 0x0B ) > + } > + } > + Method ( _PRS ) { > + Return ( BUFA ) > + } > + Method ( _DIS ) { > + Or ( PIRA, 0x80, PIRA ) > + } > + Method ( _CRS ) { > + And ( PIRA, 0x0f, Local0 ) > + ShiftLeft ( 0x1, Local0, IRQV ) > + Return ( BUFB ) > + } > + Method ( _SRS, 1 ) { > + CreateWordField ( ARG0, 0x01, IRQ1 ) > + FindSetRightBit ( IRQ1, Local0 ) > + Decrement ( Local0 ) > + Store ( Local0, PIRA ) > + } > + } > + Device ( LNKB ) { >[...] > + Name(PRTP, Package() > + { > + Package(){0x0001ffff, 0, \_SB.PCI0.LNKB, 0}, > + Package(){0x0001ffff, 1, \_SB.PCI0.LNKC, 0}, > + Package(){0x0001ffff, 2, \_SB.PCI0.LNKD, 0}, > + Package(){0x0001ffff, 3, \_SB.PCI0.LNKA, 0}, > + Package(){0x0002ffff, 0, \_SB.PCI0.LNKC, 0}, >[...] > + Package(){0x001fffff, 3, \_SB.PCI0.LNKC, 0}, > + }) > + > + Name(PRTA, Package() > + { > + Package(){0x0001ffff, 0, 0, 20}, > + Package(){0x0001ffff, 1, 0, 21}, > + Package(){0x0001ffff, 2, 0, 22}, > + Package(){0x0001ffff, 3, 0, 23}, > + Package(){0x0002ffff, 0, 0, 24}, >[...] > + Package(){0x001fffff, 3, 0, 18}, > + }) > + } > +} I realize this is the easiest route, but how the various hard coded numbers got generated would be completely lost, making it extremely hard to make any changes here down the road. I wonder whether the Makefile / output redirection approach couldn't be easily extended to create all that data via a shell script fragment, if retaining the C source (moved to a separate file) is indeed not an option. Nor would I think that would qualify here as someone having produced the replacement code without having looked at the original, as was suggested as a criteria before. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |