From: "Enrico Weigelt, metux IT consult" <info@metux.net>
To: Leon Romanovsky <leon@kernel.org>,
"Enrico Weigelt, metux IT consult" <info@metux.net>
Cc: Alex Williamson <alex.williamson@redhat.com>,
Amey Narkhede <ameynarkhede03@gmail.com>,
raphael.norwitz@nutanix.com, linux-pci@vger.kernel.org,
bhelgaas@google.com, linux-kernel@vger.kernel.org,
alay.shah@nutanix.com, suresh.gumpula@nutanix.com,
shyam.rajendran@nutanix.com, felipe@nutanix.com
Subject: Re: [PATCH 4/4] PCI/sysfs: Allow userspace to query and set device reset mechanism
Date: Fri, 19 Mar 2021 14:48:12 +0100 [thread overview]
Message-ID: <27aedf13-9c08-0ac7-e6ef-a027913c288a@metux.net> (raw)
In-Reply-To: <YFSgQ2RWqt4YyIV4@unreal>
On 19.03.21 13:59, Leon Romanovsky wrote:
>> I really doubt we can influence that by any technical decision here in
>> the kernel.
>
> There are subsystems that succeeded to do it, for example netdev, RDMA e.t.c.
I'd guess either hi-end / server or embedded products - already
mentioned that these are different fields. I've been talking about the
average consumer products.
OTOH, there're also very expensive vendors that are exceptionally bad,
eg. National instruments (who even are capable of breaking rpm so badly
with their proprietary packages that they open up 0day holes - i once
filed a report @FD on such a case).
>> 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 ?
>
> They do it because they are allowed to do it and not because they
> explicitly want to annoyance their customers.
Yes, they're just ignorant. They can still do that, because buy their
pretty expensive cheap-hardware. And that's mostly driven by purchase
people inside the customer organisations, who just don't care how much
damage they do to their own employers, by dictating purchase of
expensive broken-by-design hardware. ... but that's nothing we here have
any influence on - except for dissuasion and purchase boycott ...
In any case, I still fail to see why giving operators an debug knob
should make anything worse.
>> [ 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). ]
>
> I don't know about this specific Google case, but from my previous experience.
> The reasons why vendor says no to Google are usually due to licensing and legal
> issues and not open source vs. proprietary.
In short words: Google did (still does?) build their own mainboards and
FW (IIRC that's where LinuxBoot came from), but even with their HUGE
quantities (they buy cpus in quantities of truck loads) they still did
not manage to get any specs for writing their own early init w/o the
proprietary FSP.
The licensing / legal issues can either be:
a) we, the mightly Intel Corp., have been so extremly stupid for
licensing some vital IP stuff (what exactly could that be, in exactly
the prime domain of Intel ?) and signing such insane crontracts, that
we're not allowed to tell anybody how to actually use our own
products (yes: initializing the CPU and built-in interfaces belongs
exactly into that category)
b) we, the mighty Intel Corp., couldn't build something on our own, but
just stolen IP (in our primary domain) and are scared that anybody
could find out from just reading some early setup code.
c) we, the mighty Intel Corp., rule the world and we give a phrack on
what some tiny Customers like Google want from us.
d) we, the mightly Intel Corp., did do what our name tells: INTEL,
and we don't want anybody raise unpleasant questions.
choose your poison :P
--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@metux.net -- +49-151-27565287
next prev parent reply other threads:[~2021-03-19 13:49 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-12 17:34 [PATCH 0/4] Expose and manage PCI device reset ameynarkhede03
2021-03-12 17:34 ` [PATCH 1/4] PCI: Refactor pcie_flr to follow calling convention of other reset methods ameynarkhede03
2021-03-12 17:34 ` [PATCH 2/4] PCI: Add new bitmap for keeping track of supported reset mechanisms ameynarkhede03
2021-03-14 23:51 ` Pali Rohár
2021-03-12 17:34 ` [PATCH 3/4] PCI: Remove reset_fn field from pci_dev ameynarkhede03
2021-03-14 23:52 ` Pali Rohár
2021-03-12 17:34 ` [PATCH 4/4] PCI/sysfs: Allow userspace to query and set device reset mechanism ameynarkhede03
2021-03-14 23:55 ` Pali Rohár
2021-03-15 13:43 ` Amey Narkhede
2021-03-15 13:52 ` Pali Rohár
2021-03-15 14:34 ` Alex Williamson
2021-03-15 14:52 ` Pali Rohár
2021-03-15 15:03 ` Alex Williamson
2021-03-17 19:02 ` Pali Rohár
2021-03-17 19:15 ` Alex Williamson
2021-03-17 19:24 ` Pali Rohár
2021-03-17 19:32 ` Alex Williamson
2021-03-17 19:40 ` Pali Rohár
2021-03-17 20:00 ` Alex Williamson
2021-03-17 20:13 ` Pali Rohár
2021-03-18 14:31 ` Amey Narkhede
2021-03-23 14:34 ` Pali Rohár
2021-03-23 14:44 ` Alex Williamson
2021-03-23 15:32 ` Amey Narkhede
2021-03-23 16:06 ` Alex Williamson
2021-03-23 16:15 ` Alex Williamson
2021-03-15 15:07 ` Leon Romanovsky
2021-03-15 15:33 ` Amey Narkhede
2021-03-15 16:29 ` Alex Williamson
2021-03-15 18:32 ` Raphael Norwitz
2021-03-17 4:20 ` Leon Romanovsky
2021-03-17 10:24 ` Amey Narkhede
2021-03-17 11:02 ` Leon Romanovsky
2021-03-17 11:23 ` Amey Narkhede
2021-03-17 11:47 ` Leon Romanovsky
2021-03-17 13:17 ` Amey Narkhede
2021-03-17 13:58 ` Leon Romanovsky
2021-03-17 17:31 ` Alex Williamson
2021-03-18 9:09 ` Leon Romanovsky
2021-03-18 14:22 ` Amey Narkhede
2021-03-18 14:57 ` Leon Romanovsky
2021-03-18 17:01 ` Amey Narkhede
2021-03-18 17:35 ` Leon Romanovsky
2021-03-18 17:43 ` Amey Narkhede
2021-03-18 18:14 ` Enrico Weigelt, metux IT consult
2021-03-19 13:05 ` Leon Romanovsky
2021-03-19 15:23 ` Amey Narkhede
2021-03-19 15:37 ` Leon Romanovsky
2021-03-19 15:53 ` Amey Narkhede
2021-03-18 17:58 ` Enrico Weigelt, metux IT consult
2021-03-19 13:07 ` Leon Romanovsky
2021-03-18 16:39 ` Alex Williamson
2021-03-18 17:22 ` Leon Romanovsky
2021-03-18 17:38 ` Amey Narkhede
2021-03-18 18:34 ` Enrico Weigelt, metux IT consult
2021-03-19 12:59 ` Leon Romanovsky
2021-03-19 13:48 ` Enrico Weigelt, metux IT consult [this message]
2021-03-19 15:51 ` Leon Romanovsky
2021-03-19 15:57 ` Bjorn Helgaas
2021-03-19 16:24 ` Leon Romanovsky
2021-03-19 16:23 ` Alex Williamson
2021-03-20 9:10 ` Leon Romanovsky
2021-03-20 14:59 ` Alex Williamson
2021-03-21 8:40 ` Leon Romanovsky
2021-03-21 14:57 ` Amey Narkhede
2021-03-22 17:10 ` Alex Williamson
2021-03-24 10:03 ` Leon Romanovsky
2021-03-24 14:37 ` Alex Williamson
2021-03-24 15:13 ` Leon Romanovsky
2021-03-24 17:17 ` Alex Williamson
2021-03-25 8:37 ` Leon Romanovsky
2021-03-25 14:55 ` Alex Williamson
2021-03-25 16:09 ` Leon Romanovsky
2021-03-25 17:22 ` Amey Narkhede
2021-03-25 17:36 ` Leon Romanovsky
2021-03-25 17:53 ` Alex Williamson
2021-03-26 6:40 ` Leon Romanovsky
2021-03-26 9:18 ` Krzysztof Wilczyński
2021-03-26 12:54 ` Leon Romanovsky
2021-03-26 14:20 ` Alex Williamson
2021-03-27 6:02 ` Leon Romanovsky
2021-03-25 16:26 ` Amey Narkhede
2021-03-25 16:46 ` Leon Romanovsky
2021-03-18 17:51 ` Enrico Weigelt, metux IT consult
[not found] ` <20210312112043.3f2954e3@omen.home.shazbot.org>
2021-03-12 18:40 ` [PATCH 0/4] Expose and manage PCI device reset Amey Narkhede
2021-03-12 18:58 ` Krzysztof Wilczyński
2021-03-12 19:06 ` Amey Narkhede
2021-03-12 19:20 ` Krzysztof Wilczyński
2021-03-13 2:02 ` Raphael Norwitz
2021-03-14 12:09 ` Leon Romanovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=27aedf13-9c08-0ac7-e6ef-a027913c288a@metux.net \
--to=info@metux.net \
--cc=alay.shah@nutanix.com \
--cc=alex.williamson@redhat.com \
--cc=ameynarkhede03@gmail.com \
--cc=bhelgaas@google.com \
--cc=felipe@nutanix.com \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=raphael.norwitz@nutanix.com \
--cc=shyam.rajendran@nutanix.com \
--cc=suresh.gumpula@nutanix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).