linux-kernel - Re: [PATCH] net: add QCA alx Ethernet driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120322092727.GA21284@electric-eye.fr.zoreil.com>
Date:	Thu, 22 Mar 2012 10:27:27 +0100
From:	Francois Romieu <romieu@...zoreil.com>
To:	"Luis R. Rodriguez" <rodrigue@....qualcomm.com>
Cc:	David Miller <davem@...emloft.net>, xiong@....qualcomm.com,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	qca-linux-team@...lcomm.com, nic-devel@...lcomm.com,
	kgiori@....qualcomm.com, chris.snook@...il.com,
	mathieu@....qualcomm.com, bryanh@...cinc.com,
	Jesper Andersen <jespera@...u.dk>, Julia Lawall <julia@...u.dk>
Subject: Re: [PATCH] net: add QCA alx Ethernet driver

Luis R. Rodriguez <rodrigue@....qualcomm.com> :
> On Tue, Feb 28, 2012 at 7:32 PM, David Miller <davem@...emloft.net> wrote:
[...]
> > To be honest tg3, as one example, supports quite a large array of
> > different pieces of hardware that use the same logical core.
> 
> At certain point it becomes a pain in the ass to support older
> chipsets, and simply easier to leave the older driver to rot.

I would avoid saying such things while trying to sell a plan for a bright
future of drivers maintained and supported by $BIGCORP. :o)

[...]
> Would it be worthwhile to consider alx upstream only for the newer
> chipsets (regardless of the litmus test, which I do agree with on
> technical grounds) in consideration for helping pave the way on
> killing proprietary drivers?

What is the situation regarding the availability for public use of
programming manuals and errata on older chipsets ?

I am fine with Qualcomm being completely uninterested in maintaining
code for old chipsets and dedicating manpower or $$$ on it, be it now,
tomorrow or after a new arrival of management execs. However it sends
a bad message if code for new chipsets comes in while users have to
maintain their pile of poo in the dark.

The hardware stays for years. It's one of the engineering problems of
the day. Killing proprietary drivers is an interesting goal but it is
far, far away.

Qualcomm should imvho meet davem's remarks with more short termed
deliverables.

-- 
Ueimor
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/