On Fri, Sep 27, 2019 at 3:58 PM Aaron Durbin via coreboot
wrote:
>> >
>> > 5. PCI coalesce can alter PCI dev.fn assignments?
>>
>> That's a serious problem. I noticed that CFL FSP can reassign them
>> without being asked to, unpredictably (e.g. if a device fails to show
>> up in whatever timeframe
On Fri, Sep 27, 2019 at 8:11 PM Nico Huber wrote:
>
> On 26.09.19 18:45, Aaron Durbin via coreboot wrote:
> > Here's some of the requirements/issues we should resolve that come to mind:
> >
> > 1. Easy way to directly retrieve a device's chip config object w/o
> > traversing the device hierarchy.
On Fri, Sep 27, 2019 at 10:42 AM Nico Huber wrote:
> On 27.09.19 15:42, Kyösti Mälkki wrote:
> > On Thu, Sep 26, 2019 at 7:45 PM Aaron Durbin wrote:
> >>
> >> On Thu, Sep 26, 2019 at 10:06 AM Kyösti Mälkki
> wrote:
> >>> Should be easy enough to implement
> >>> platform hook telling to not remo
On Fri, Sep 27, 2019 at 11:11 AM Nico Huber wrote:
> On 26.09.19 18:45, Aaron Durbin via coreboot wrote:
> > Here's some of the requirements/issues we should resolve that come to
> mind:
> >
> > 1. Easy way to directly retrieve a device's chip config object w/o
> > traversing the device hierarchy
On Fri, Sep 27, 2019 at 7:42 PM Nico Huber wrote:
>
> IIRC, I asked this elsewhere already. Do we want to keep simple device?
> If we reduce `struct device` to b/d/f and a pointer to the chip info
> in early stages, couldn't we just use `struct device` for PCI config
> access everywhere?
I got si
On 26.09.19 18:45, Aaron Durbin via coreboot wrote:
> Here's some of the requirements/issues we should resolve that come to mind:
>
> 1. Easy way to directly retrieve a device's chip config object w/o
> traversing the device hierarchy. Which leads to...
> 2. Symbol alias for accessing struct device
On 27.09.19 15:42, Kyösti Mälkki wrote:
> On Thu, Sep 26, 2019 at 7:45 PM Aaron Durbin wrote:
>>
>> On Thu, Sep 26, 2019 at 10:06 AM Kyösti Mälkki
>> wrote:
>>> Should be easy enough to implement
>>> platform hook telling to not remove PCI device node from topology
>>> links (based on BDF), even
On Thu, Sep 26, 2019 at 7:45 PM Aaron Durbin wrote:
>
> On Thu, Sep 26, 2019 at 10:06 AM Kyösti Mälkki
> wrote:
>> Should be easy enough to implement
>> platform hook telling to not remove PCI device node from topology
>> links (based on BDF), even when it does not respond to ID queries.
>
>
> Y
On Thu, Sep 26, 2019 at 10:06 AM Kyösti Mälkki
wrote:
> In a nutshell:
>
> The implementation of dev_find_slot() traverses the linked list of all
> devices in the devicetree, regardless of the topology. Since PCI bus
> numbers are only assigned in early ramstage, this function is not a
> reliable
In a nutshell:
The implementation of dev_find_slot() traverses the linked list of all
devices in the devicetree, regardless of the topology. Since PCI bus
numbers are only assigned in early ramstage, this function is not a
reliable API. Furthermore, referencing (dynamically) assigned PCI
busses by
On Thu, Sep 26, 2019 at 8:51 AM Kyösti Mälkki
wrote:
> Hi Matt,
>
> thanks for bringing the topic up. Please also contact your Intel reps
> about this via commercial support channel as well. I believe Patrick
> G. once stated that he could act as a relay when it comes to disputes
> between commer
Kyösti Mälkki:
> Preferably fix FSP and not allow this PCI hide-and-seek.
Only for my own education, is that related to
https://www.spinics.net/lists/kernel/msg2709360.html?
--
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste
Hi Matt,
thanks for bringing the topic up. Please also contact your Intel reps
about this via commercial support channel as well. I believe Patrick
G. once stated that he could act as a relay when it comes to disputes
between commercial and community development 'strategies'.
On Wed, Sep 25, 2019
13 matches
Mail list logo
