Hi,
On 2023/7/26 05:49, Bjorn Helgaas wrote:
On Sat, Jul 22, 2023 at 04:11:07PM +0800, suijingfeng wrote:
...
In the future, we may want to expand VGAARB to deal all PCI display class
devices, with another patch.
if (pdev->class >> 16 == PCI_BASE_CLASS_DISPLAY)
// accept
else
On Sat, Jul 22, 2023 at 04:11:07PM +0800, suijingfeng wrote:
> ...
> In the future, we may want to expand VGAARB to deal all PCI display class
> devices, with another patch.
>
> if (pdev->class >> 16 == PCI_BASE_CLASS_DISPLAY)
>
> // accept
>
> else
>
> // return immediately.
>
Hi,
On 2023/7/20 02:26, Bjorn Helgaas wrote:
Optimization is fine, but the most important thing here is to be clear
about what functional change this patch makes. As I mentioned at [1],
if this patch affects the class codes accepted, please make that clear
here.
Reviewed-by: Mario Limonciello
Hi,
On 2023/7/20 05:13, Sui Jingfeng wrote:
Otherwise there 30+ noisy(useless) events got snooped. See below:
```
[ 0.246077] pci :01:00.0: vgaarb: setting as boot VGA device
[ 0.246077] pci :01:00.0: vgaarb: bridge control possible
[ 0.246077] pci :01:00.0: vgaarb: VGA d
Hi,
On 2023/7/20 02:26, Bjorn Helgaas wrote:
On Tue, Jul 11, 2023 at 09:43:50PM +0800, Sui Jingfeng wrote:
From: Sui Jingfeng
Currently, vgaarb only cares about PCI VGA-compatible class devices.
While vga_arbiter_del_pci_device() gets called unbalanced when some PCI
device is about to be rem
On 2023/7/20 03:58, Sui Jingfeng wrote:
On the other hand, even though the lest significant 8 but if
pdev->class is really matter.
If the low eight bits of pdev->class is really matters,
maybe we should wait the potential problems became severe.
Currently, it is not obvious.
On 2023/7/20 03:58, Sui Jingfeng wrote:
My explanation about the minor tweak being made before this version
and previous version
is that I want to keep my patch *less distraction*.
The minor tweak being made between this version and previous version is
to keep my patch *less distraction
On 2023/7/20 03:58, Sui Jingfeng wrote:
What this version adds here is *same* before this patch set is applied.
The filter method is *same* , in the cases of before this patch is
applied and after this patch is applied.
Hi,
On 2023/7/20 02:26, Bjorn Helgaas wrote:
On Tue, Jul 11, 2023 at 09:43:50PM +0800, Sui Jingfeng wrote:
[...]
Reviewed-by: Mario Limonciello
Signed-off-by: Sui Jingfeng
I do not see Mario's Reviewed-by on the list. I do see Mario's
Reviewed-by [2] for a previous version, but that versi
On Tue, Jul 11, 2023 at 09:43:50PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> Currently, vgaarb only cares about PCI VGA-compatible class devices.
>
> While vga_arbiter_del_pci_device() gets called unbalanced when some PCI
> device is about to be removed. This happens even during the bo
On 2023/7/17 21:17, Sui Jingfeng wrote:
So without we can craft something new easily without significant change.
Therefore, We can *NOT* craft something new easily without significant
change.
Especially userspace changes.
So my current patch choose to keep the original behavior.
At the sa
Hi,
On 2023/7/17 17:51, suijingfeng wrote:
Hi,
On 2023/7/11 21:43, Sui Jingfeng wrote:
From: Sui Jingfeng
Currently, vgaarb only cares about PCI VGA-compatible class devices.
While vga_arbiter_del_pci_device() gets called unbalanced when some PCI
device is about to be removed. This happens
Hi,
On 2023/7/11 21:43, Sui Jingfeng wrote:
From: Sui Jingfeng
Currently, vgaarb only cares about PCI VGA-compatible class devices.
While vga_arbiter_del_pci_device() gets called unbalanced when some PCI
device is about to be removed. This happens even during the boot process.
Another reason
From: Sui Jingfeng
Currently, vgaarb only cares about PCI VGA-compatible class devices.
While vga_arbiter_del_pci_device() gets called unbalanced when some PCI
device is about to be removed. This happens even during the boot process.
Another reason is that the vga_arb_device_init() function is
14 matches
Mail list logo
