[Meego-kernel] [PATCH 1/2] Add support for Broadcom BCM4751 GPS chip
sakari.poussa at nokia.com
sakari.poussa at nokia.com
Fri Nov 5 07:03:25 PDT 2010
On 5/11/10 12:13 AM, "ext Greg KH" <gregkh at suse.de> wrote:
> On Thu, Nov 04, 2010 at 09:49:08PM +0100, sakari.poussa at nokia.com wrote:
>> On 4/11/10 4:26 PM, "ext Alan Cox" <alan at linux.intel.com> wrote:
>>>>> Why isn't this driver upstream?
>>>> We tried. No success.
>>> You didn't try very hard it seems ?
>> Maybe. The feedback was pretty clear. With this setup there is not path to
> Exactly, so please fix the code.
There is nothing to fix in the code. The license needs to be fixed which
involves lawyers which takes time.
>>> And is the spec in question still closed, is the hardware in fact
>>> tightly tied to a non-free userspace ?
>> Nothing has changed in the spec and how to get it. I don't see the situation
>> changing anytime soon.
> Why not? Isn't the fact that you can't get the driver accepted without
> changing this be a reason to get it changed?
>>> With my upstream hat on we have to be very careful about this because a
>>> GPL piece of kernel code closely tied to and not usable without a
>>> non-free component could be considered to be one work and then we get
>>> into the realm of people in suits ties and briefcases, which is a place
>>> we prefer not to go.
>>> Secondly its very bad to have undocumented, untestable interfaces which
>>> is what you are asking for.
>>> I appreciate there may be reasons it's been done that way, for example
>>> if the GPS enforces the checks against certain classes of usage in
>>> software but again with kernel upstream hat on, our primary job is to
>>> make sure the kernel is testable, documented, complete and open.
>> All of your arguments are valid. On the other hand, we need the code one way
>> or the other to make products based on MeeGo. That is our primary target.
>> And we'd like to keep the delta between that MeeGo and mainline minimal. So
>> if the driver does not go to mainline, next option is to include it in
>> MeeGo. And if that is not possible, the worst option is that we keep
>> maintaining our own product tree inside Nokia. This is not what we want.
> So you want someone else to maintain the driver in their tree instead of
> having to do it yourself, despite the problem being your own company's
> issue? That's extreemly selfish.
I did not say somebody else will maintain the code. You are making that
assumption. That's extremely wrong.
Instead, Nokia should maintain that code in MeeGo if that ends up being the
final destination of the driver.
>> It's not an ideal world. We need to make compromises somewhere.
> Why force other people to make those compromises? It's not Intel's
> issue, it is Nokia's.
> good luck,
> greg k-h
More information about the MeeGo-kernel