Re: [PATCH v4 02/21] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

On 09/21/2016 06:39 AM, Jan Beulich wrote:
>>>> On 20.09.16 at 02:19, <boris.ostrovsky@oracle.com> wrote:
>> --- a/tools/firmware/hvmloader/acpi/dsdt.asl
>> +++ /dev/null
> Please try to represent this as a move, not as a delete+create.

This was done by 'git mv' and patches were generated with 'git
format-patch -M5 ...' so I am not sure how I can convince git to show it
as a rename. Maybe increase the argument to -M to something higher?


>
>> +    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.

I can do that (but then I think it would also make sense to have it
generate _S5 and _PIC methods as well, even though they are "static").

I think bash script would be better than C since we mostly care about
loops that generate values and not language constructs such as stmt()
and push_blk().

-boris



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel