Michael Krufky <[email protected]> wrote:
>
> +struct dvb_pll_desc dvb_pll_tdhu2 = {
> + .name = "ALPS TDHU2",
> + .min = 54000000,
> + .max = 864000000,
> + .count = 4,
> + .entries = {
> + { 162000000, 44000000, 62500, 0x85, 0x01 },
> + { 426000000, 44000000, 62500, 0x85, 0x02 },
> + { 782000000, 44000000, 62500, 0x85, 0x08 },
> + { 999999999, 44000000, 62500, 0x85, 0x88 },
> + }
> +};
> +EXPORT_SYMBOL(dvb_pll_tdhu2);
The new driver is to have a GPL license, I assume?
Generally, EXPORT_SYMBOL_GPL seems more appropriate for the DVB subsystem.
Andrew Morton wrote:
>Michael Krufky <[email protected]> wrote:
>
>
>>+struct dvb_pll_desc dvb_pll_tdhu2 = {
>> + .name = "ALPS TDHU2",
>> + .min = 54000000,
>> + .max = 864000000,
>> + .count = 4,
>> + .entries = {
>> + { 162000000, 44000000, 62500, 0x85, 0x01 },
>> + { 426000000, 44000000, 62500, 0x85, 0x02 },
>> + { 782000000, 44000000, 62500, 0x85, 0x08 },
>> + { 999999999, 44000000, 62500, 0x85, 0x88 },
>> + }
>> +};
>> +EXPORT_SYMBOL(dvb_pll_tdhu2);
>>
>>
>
>The new driver is to have a GPL license, I assume?
>
>Generally, EXPORT_SYMBOL_GPL seems more appropriate for the DVB subsystem.
>
Yes, GPL'd of course. But these pll definitions are not strictly tied
to nxt200x -- they may very well be used by another frontend module in
the future.
Actually, we keep pll info in a separate file (dvb-pll.c) so that the
tuner programming can be used by any frontend module, depending on the
design..... About EXPORT_SYMBOL, this is how it's done all over dvb-pll.c
If this needs to change, then it should apply to the entire dvb-pll.
I'll wait for Johannes' comments on this.
Michael Krufky
Mike Krufky wrote:
> Andrew Morton wrote:
>
>> Michael Krufky <[email protected]> wrote:
>>
>>
>>> +struct dvb_pll_desc dvb_pll_tdhu2 = {
>>> + .name = "ALPS TDHU2",
>>> + .min = 54000000,
>>> + .max = 864000000,
>>> + .count = 4,
>>> + .entries = {
>>> + { 162000000, 44000000, 62500, 0x85, 0x01 },
>>> + { 426000000, 44000000, 62500, 0x85, 0x02 },
>>> + { 782000000, 44000000, 62500, 0x85, 0x08 },
>>> + { 999999999, 44000000, 62500, 0x85, 0x88 },
>>> + }
>>> +};
>>> +EXPORT_SYMBOL(dvb_pll_tdhu2);
>>>
>>
>>
>> The new driver is to have a GPL license, I assume?
>>
>> Generally, EXPORT_SYMBOL_GPL seems more appropriate for the DVB
>> subsystem.
>>
Hello Andrew,
We have in the DVB subsystem most of the exported symbols as
EXPORT_SYMBOL itself, rather than EXPORT_SYMBOL_GPL. I think if this
needs to be changed, we would require a global change of all symbols to
the same to maintain consistency. If you require that change we can have
a change but i would think that the discussions be done with the
relevant copyright holders too, eventhough probably most of the authors
won't have any objection.
> Yes, GPL'd of course. But these pll definitions are not strictly tied
> to nxt200x -- they may very well be used by another frontend module in
> the future.
>
> Actually, we keep pll info in a separate file (dvb-pll.c) so that the
> tuner programming can be used by any frontend module, depending on the
> design..... About EXPORT_SYMBOL, this is how it's done all over dvb-pll.c
>
> If this needs to change, then it should apply to the entire dvb-pll.
>
It is not necessary limited to dvb-pll, but the entire dvb-kernel.
Thanks,
Manu
On Fri, 2005-11-04 at 03:46 +0400, Manu Abraham wrote:
> We have in the DVB subsystem most of the exported symbols as
> EXPORT_SYMBOL itself, rather than EXPORT_SYMBOL_GPL. I think if this
> needs to be changed, we would require a global change of all symbols to
> the same to maintain consistency. If you require that change we can have
> a change but i would think that the discussions be done with the
> relevant copyright holders too, eventhough probably most of the authors
> won't have any objection.
I don't know if I ever contributed code to the DVB subsystem which is
actually exported, but in case I did, then I am against changing the
affected EXPORT_SYMBOLs.
This would make it impossible to the use source code of most hardware
vendors for embedded products because they usually have different
licenses for their "run-on-every-embedded-platform-and-even-on-windows"
drivers.
Also I remember people telling on lkml that EXPORT_SYMBOL_GPL was used
for new kernel internal code only and I can't see how this applies to
dvb-pll or any other part of the dvb subsystem which grew up outside the
kernel tree.
Regards,
Andreas
Andreas Oberritter wrote:
>On Fri, 2005-11-04 at 03:46 +0400, Manu Abraham wrote:
>
>
>>We have in the DVB subsystem most of the exported symbols as
>>EXPORT_SYMBOL itself, rather than EXPORT_SYMBOL_GPL. I think if this
>>needs to be changed, we would require a global change of all symbols to
>>the same to maintain consistency. If you require that change we can have
>>a change but i would think that the discussions be done with the
>>relevant copyright holders too, eventhough probably most of the authors
>>won't have any objection.
>>
>>
>
>I don't know if I ever contributed code to the DVB subsystem which is
>actually exported, but in case I did, then I am against changing the
>affected EXPORT_SYMBOLs.
>
>
Since this issue is subject to discussion, i think a consensus can be
reached, with a discussion with the relevant owners, _if_ it needs to be
changed. I did not imply that it needs to be changed.
I have personally contributed some code which does EXPORT_SYMBOL, but
for me changing it to EXPORT_SYMBOL_GPL is acceptable if the general
consensus is that way, or if there is a valid reason to go either way. I
don't mind either.
>This would make it impossible to the use source code of most hardware
>vendors for embedded products because they usually have different
>licenses for their "run-on-every-embedded-platform-and-even-on-windows"
>drivers.
>
>Also I remember people telling on lkml that EXPORT_SYMBOL_GPL was used
>for new kernel internal code only and I can't see how this applies to
>dvb-pll or any other part of the dvb subsystem which grew up outside the
>kernel tree.
>
>
AFAIK, the only hardware that exports EXPORT_SYMBOL_GPL is only the
budget core, other than that all of the code uses EXPORT_SYMBOL only.
Regards,
Manu
Andreas Oberritter writes:
> On Fri, 2005-11-04 at 03:46 +0400, Manu Abraham wrote:
> > We have in the DVB subsystem most of the exported symbols as
> > EXPORT_SYMBOL itself, rather than EXPORT_SYMBOL_GPL. I think if this
> > needs to be changed, we would require a global change of all symbols to
> > the same to maintain consistency. If you require that change we can have
> > a change but i would think that the discussions be done with the
> > relevant copyright holders too, eventhough probably most of the authors
> > won't have any objection.
>
> I don't know if I ever contributed code to the DVB subsystem which is
> actually exported, but in case I did, then I am against changing the
> affected EXPORT_SYMBOLs.
>
> This would make it impossible to the use source code of most hardware
> vendors for embedded products because they usually have different
> licenses for their "run-on-every-embedded-platform-and-even-on-windows"
> drivers.
>
> Also I remember people telling on lkml that EXPORT_SYMBOL_GPL was used
> for new kernel internal code only and I can't see how this applies to
> dvb-pll or any other part of the dvb subsystem which grew up outside the
> kernel tree.
AFAIK, the DVB core is also purposely using an LGPL license to allow
drivers with other licenses to at least use the DVB includes/calls.
Regards,
Ralph