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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.09.16 at 15:34, <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 09/21/2016 06:39 AM, Jan Beulich wrote:
>>>>> 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.
> 
> 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?

Or perhaps with the other adjustment carried out, the delta will
become small enough.

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

Sounds reasonable.

Jan


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