linux-kernel - Re: [PATCH 4/4] PCI/sysfs: Allow userspace to query and set device reset mechanism

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: <a2b9dc7e-e73a-3a70-5899-8ed37a8ef700@metux.net>
Date:   Thu, 18 Mar 2021 19:34:56 +0100
From:   "Enrico Weigelt, metux IT consult" <info@...ux.net>
To:     Leon Romanovsky <leon@...nel.org>,
        Alex Williamson <alex.williamson@...hat.com>
Cc:     Amey Narkhede <ameynarkhede03@...il.com>,
        raphael.norwitz@...anix.com, linux-pci@...r.kernel.org,
        bhelgaas@...gle.com, linux-kernel@...r.kernel.org,
        alay.shah@...anix.com, suresh.gumpula@...anix.com,
        shyam.rajendran@...anix.com, felipe@...anix.com
Subject: Re: [PATCH 4/4] PCI/sysfs: Allow userspace to query and set device
 reset mechanism

On 18.03.21 18:22, Leon Romanovsky wrote:

> Which email client do you use?
> Your responses are grouped as one huge block without any chance to respond
> to you on specific point or answer to your question.

I'm reading this thread in Tbird, and threading / quoting all looks
nice.

> I see your flow and understand your position, but will repeat my
> position. We need to make sure that vendors will have incentive to
> supply quirks.

I really doubt we can influence that by any technical decision here in
the kernel.

> And regarding vendors, see Amey response below about his touchpad troubles.
> The cheap electronics vendors don't care about their users.

IMHO, the expensive ones don't care either.

Does eg. Dell publish board schematics ? Do they even publish exact part
lists (exact chipsets) along with their brochures, so customers can
check wether their HW is supported, before buying and trying out ?

Doesn't seem so. I've personally seen a lot cases where some supposedly
supported HW turned out to be some completely different and unsupported
HW that's sold under exactly the same product ID. One of many reasons
for not giving them a single penny anymore.

IMHO, there're only very few changes of convincing some HW vendor for
doing a better job on driver side:

a) product is targeted for a niche that can't live without Linux
    (eg. embedded)
b) it's really *dangerous* for your market share if anything doesn't
    work properly on Linux (eg. certan server machines)
c) somebody *really* big (like Google) is gun-pointing at some supplier,
    who's got a lot to loose
d) a *massive* worldwide shitstorm against the vendor

[ And often, even a combination of them isn't enough. Did you know that
   even Google doesn't get all specs necessary to replace away the ugly
   FSP blob ? (it's the same w/ AMD, but meanwhile I'm pissed enought to
   reverse engineer their AGESA blob). ]

You see, what we do here in the kernel has no practical influence on
those hw vendors.

--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@...ux.net -- +49-151-27565287