Re: [PATCH v2 01/15] platform/x86: dell-uart-backlight: Use blacklight power constant

2025-07-22 Thread Ilpo Järvinen
On Mon, 21 Jul 2025, Thomas Zimmermann wrote: > Hi > > Am 21.07.25 um 13:43 schrieb Ilpo Järvinen: > > On Tue, 15 Jul 2025, Thomas Zimmermann wrote: > > > > > The backlight subsystem has gotten its own power constants. Replace > > > FB_BLANK_UNBLANK with

Re: [PATCH v2 01/15] platform/x86: dell-uart-backlight: Use blacklight power constant

2025-07-21 Thread Ilpo Järvinen
On Tue, 15 Jul 2025, Thomas Zimmermann wrote: > The backlight subsystem has gotten its own power constants. Replace > FB_BLANK_UNBLANK with BACKLIGHT_POWER_ON. > > Signed-off-by: Thomas Zimmermann > Reviewed-by: Hans de Goede > Acked-by: Ilpo Järvinen > --- > driver

Re: [PATCH 01/12] platform/x86: dell-uart-backlight: Use blacklight power constant

2025-06-24 Thread Ilpo Järvinen
e */ > - ret = dell_uart_set_bl_power(dell_bl, FB_BLANK_UNBLANK); > + ret = dell_uart_set_bl_power(dell_bl, BACKLIGHT_POWER_ON); > if (ret) > return ret; Acked-by: Ilpo Järvinen -- i.

Re: [PATCH v2 0/1] MAINTAINERS: .mailmap: Update Hans de Goede's email address

2025-06-10 Thread Ilpo Järvinen
On Mon, 09 Jun 2025 16:35:56 +0200, Hans de Goede wrote: > I'm moving all my kernel work over to using my kernel.org email address. > > The single patch in this series updates .mailmap and all MAINTAINERS > entries still using hdego...@redhat.com. > > Since most of my work is pdx86 related I bel

Re: [PATCH v9 5/6] PCI: Allow drivers to control VF BAR size

2025-06-04 Thread Ilpo Järvinen
ci_dev *dev, bool probe); > > /* Arch may override these (weak) */ > @@ -2489,6 +2491,10 @@ static inline int pci_sriov_get_totalvfs(struct > pci_dev *dev) > #define pci_sriov_configure_simple NULL > static inline resource_size_t pci_iov_resource_size(struct pci_dev *dev, int > resno) > { return 0; } > +static inline int pci_iov_vf_bar_set_size(struct pci_dev *dev, int resno, > int size) > +{ return -ENODEV; } > +static inline u32 pci_iov_vf_bar_get_sizes(struct pci_dev *dev, int resno, > int num_vfs) > +{ return 0; } > static inline void pci_vf_drivers_autoprobe(struct pci_dev *dev, bool probe) > { } > #endif > > Reviewed-by: Ilpo Järvinen -- i.

Re: [PATCH 02/34] platform: arm64: acer-aspire1-ec: convert to devm_drm_bridge_alloc() API

2025-04-07 Thread Ilpo Järvinen
On Mon, 7 Apr 2025, Luca Ceresoli wrote: > This is the new API for allocating DRM bridges. > > Signed-off-by: Luca Ceresoli > > --- > > Cc: "Bryan O'Donoghue" > Cc: "Ilpo Järvinen" > Cc: Hans de Goede > --- > drivers/platfor

Re: [PATCH v7 3/6] PCI: Allow IOV resources to be resized in pci_resize_resource()

2025-04-05 Thread Ilpo Järvinen
e_sizes(dev, resno); > @@ -459,7 +484,7 @@ int pci_resize_resource(struct pci_dev *dev, int resno, > int size) > if (ret) > return ret; > > - resource_set_size(res, pci_rebar_size_to_bytes(size)); > + pci_resize_resource_set_size(dev, resno, size); > > /* Check if the new config works by trying to assign everything. */ > if (dev->bus->self) { > @@ -471,7 +496,7 @@ int pci_resize_resource(struct pci_dev *dev, int resno, > int size) > > error_resize: > pci_rebar_set_size(dev, resno, old); > - resource_set_size(res, pci_rebar_size_to_bytes(old)); > + pci_resize_resource_set_size(dev, resno, old); > return ret; > } > EXPORT_SYMBOL(pci_resize_resource); Reviewed-by: Ilpo Järvinen -- i.

Re: [PATCH v7 5/6] PCI: Allow drivers to control VF BAR size

2025-04-03 Thread Ilpo Järvinen
On Wed, 2 Apr 2025, Michał Winiarski wrote: > Drivers could leverage the fact that the VF BAR MMIO reservation is > created for total number of VFs supported by the device by resizing the > BAR to larger size when smaller number of VFs is enabled. > > Add a pci_iov_vf_bar_set_size() function to c

Re: [PATCH v7 4/6] PCI/IOV: Check that VF BAR fits within the reservation

2025-04-03 Thread Ilpo Järvinen
> resource_size(res)) > + continue; > if (res->parent) > nres++; > } > Reviewed-by: Ilpo Järvinen -- i.

Re: [PATCH v7 2/6] PCI: Add a helper to convert between VF BAR number and IOV resource

2025-04-03 Thread Ilpo Järvinen
On Wed, 2 Apr 2025, Michał Winiarski wrote: > There are multiple places where conversions between IOV resources and > corresponding VF BAR numbers are done. > > Extract the logic to pci_resource_num_from_vf_bar() and > pci_resource_num_to_vf_bar() helpers. > > Sugges

Re: [PATCH v6 5/6] PCI: Allow drivers to control VF BAR size

2025-04-02 Thread Ilpo Järvinen
On Wed, 2 Apr 2025, Michał Winiarski wrote: > On Wed, Mar 26, 2025 at 05:22:50PM +0200, Ilpo Järvinen wrote: > > On Thu, 20 Mar 2025, Michał Winiarski wrote: > > > > > Drivers could leverage the fact that the VF BAR MMIO reservation is > > > created for tot

Re: [PATCH v6 4/6] PCI/IOV: Check that VF BAR fits within the reservation

2025-03-28 Thread Ilpo Järvinen
On Wed, 26 Mar 2025, Ilpo Järvinen wrote: > On Thu, 20 Mar 2025, Michał Winiarski wrote: > > > When the resource representing VF MMIO BAR reservation is created, its > > size is always large enough to accommodate the BAR of all SR-IOV Virtual > > Functions that can poten

Re: [PATCH v6 3/6] PCI: Allow IOV resources to be resized in pci_resize_resource()

2025-03-26 Thread Ilpo Järvinen
On Thu, 20 Mar 2025, Michał Winiarski wrote: > Similar to regular resizable BAR, VF BAR can also be resized. > > The structures are very similar, which means we can reuse most of the > implementation. There are differences in resizing which should be described (size calc and mem decode check).

Re: [PATCH v6 1/6] PCI/IOV: Restore VF resizable BAR state after reset

2025-03-26 Thread Ilpo Järvinen
ap. > Signed-off-by: Michał Winiarski > Reviewed-by: Ilpo Järvinen > Reviewed-by: Christian König > --- > drivers/pci/iov.c | 30 +- > drivers/pci/pci.h | 1 + > include/uapi/linux/pci_regs.h | 1 + > 3 files change

Re: [PATCH v6 6/6] drm/xe/pf: Set VF LMEM BAR size

2025-03-26 Thread Ilpo Järvinen
gt; %d\n", err); If you intended this error to not result in failure, please mention it in the changelog so that it's recorded somewhere for those who have to look up things from the git history one day :-). > + } > + > err = pci_enable_sriov(pdev, num_vfs); > if (err < 0) > goto failed; Seems pretty straightforward after reading the support code on the PCI core side, Reviewed-by: Ilpo Järvinen -- i.

Re: [PATCH v6 5/6] PCI: Allow drivers to control VF BAR size

2025-03-26 Thread Ilpo Järvinen
On Thu, 20 Mar 2025, Michał Winiarski wrote: > Drivers could leverage the fact that the VF BAR MMIO reservation is > created for total number of VFs supported by the device by resizing the > BAR to larger size when smaller number of VFs is enabled. > > Add a pci_iov_vf_bar_set_size() function to

Re: [PATCH v6 4/6] PCI/IOV: Check that VF BAR fits within the reservation

2025-03-26 Thread Ilpo Järvinen
On Thu, 20 Mar 2025, Michał Winiarski wrote: > When the resource representing VF MMIO BAR reservation is created, its > size is always large enough to accommodate the BAR of all SR-IOV Virtual > Functions that can potentially be created (total VFs). If for whatever > reason it's not possible to ac

Re: [PATCH v6 1/6] PCI/IOV: Restore VF resizable BAR state after reset

2025-03-26 Thread Ilpo Järvinen
On Wed, 26 Mar 2025, Ilpo Järvinen wrote: > On Thu, 20 Mar 2025, Michał Winiarski wrote: > > > Similar to regular resizable BAR, VF BAR can also be resized, e.g. by > > the system firmware or the PCI subsystem itself. > > > > Add the capability ID and res

Re: [PATCH v6 2/6] PCI: Add a helper to convert between VF BAR number and IOV resource

2025-03-26 Thread Ilpo Järvinen
On Thu, 20 Mar 2025, Michał Winiarski wrote: > There are multiple places where conversions between IOV resources and > corresponding VF BAR numbers are done. > > Extract the logic to pci_resource_num_from_vf_bar() and > pci_resource_num_to_vf_bar() helpers. > > Sugges

Re: [PATCH v3 14/16] platform/x86/amd/pmf: convert timeouts to secs_to_jiffies()

2025-03-21 Thread Ilpo Järvinen
On Tue, 25 Feb 2025, Easwar Hariharan wrote: > Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced > secs_to_jiffies(). As the value here is a multiple of 1000, use > secs_to_jiffies() instead of msecs_to_jiffies() to avoid the multiplication > > This is converted using scripts/

Re: [PATCH v3 15/16] platform/x86: thinkpad_acpi: convert timeouts to secs_to_jiffies()

2025-03-21 Thread Ilpo Järvinen
On Tue, 25 Feb 2025, Easwar Hariharan wrote: > Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced > secs_to_jiffies(). As the value here is a multiple of 1000, use > secs_to_jiffies() instead of msecs_to_jiffies() to avoid the multiplication > > This is converted using scripts/

Re: [PATCH v5 3/6] PCI: Allow IOV resources to be resized in pci_resize_resource()

2025-03-13 Thread Ilpo Järvinen
On Wed, 12 Mar 2025, Michał Winiarski wrote: > Similar to regular resizable BAR, VF BAR can also be resized. > > The structures are very similar, which means we can reuse most of the > implementation. > > Extend the pci_resize_resource() function to accept IOV resources. > > See PCIe r4.0, sec

Re: [PATCH v5 1/6] PCI/IOV: Restore VF resizable BAR state after reset

2025-03-13 Thread Ilpo Järvinen
On Thu, 13 Mar 2025, Ilpo Järvinen wrote: > On Wed, 12 Mar 2025, Michał Winiarski wrote: > > > Similar to regular resizable BAR, VF BAR can also be resized, e.g. by > > the system firmware or the PCI subsystem itself. > > > > Add the capability ID and res

Re: [PATCH v5 1/6] PCI/IOV: Restore VF resizable BAR state after reset

2025-03-13 Thread Ilpo Järvinen
t; Signed-off-by: Michał Winiarski > Reviewed-by: Ilpo Järvinen > Reviewed-by: Christian König > --- > drivers/pci/iov.c | 29 - > include/uapi/linux/pci_regs.h | 1 + > 2 files changed, 29 insertions(+), 1 deletion(-) > > diff --git

Re: [PATCH v3 4/7] platform: arm64: lenovo-yoga-c630: use the auxiliary device creation helper

2025-02-13 Thread Ilpo Järvinen
On Tue, 11 Feb 2025, Jerome Brunet wrote: > The auxiliary device creation of this driver is simple enough to > use the available auxiliary device creation helper. > > Use it and remove some boilerplate code. > > Signed-off-by: Jerome Brunet > --- > drivers/platform/arm64/lenovo-yoga-c630.c | 4

Re: [PATCH 14/16] platform/x86/amd/pmf: convert timeouts to secs_to_jiffies()

2025-01-29 Thread Ilpo Järvinen
On Tue, 28 Jan 2025, Easwar Hariharan wrote: > Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced > secs_to_jiffies(). As the value here is a multiple of 1000, use > secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication. > > This is converted using scripts/c

Re: [RFC 13/13] PM: standby: Add sysfs attribute for modern standby transitions

2024-11-28 Thread Ilpo Järvinen
On Thu, 21 Nov 2024, Antheas Kapenekakis wrote: > Add a sysfs attribute to allow informing the kernel about the current > standby state, those being: "active", "screen_off", "sleep", and > "resume" (to prepare turning the display on). The final modern > standby state DRIPS is omitted, as that is e

Re: [PATCH v4 3/7] PCI: Add a helper to convert between standard and IOV resources

2024-11-06 Thread Ilpo Järvinen
On Fri, 25 Oct 2024, Michał Winiarski wrote: > There are multiple places where conversions between IOV resources and > standard resources are done. > > Extract the logic to pci_resource_to_iov() and pci_resource_from_iov() > helpers. > > Suggested-by: Ilpo Järvinen &g

Re: [PATCH v2 05/10] sysfs: treewide: constify attribute callback of bin_is_visible()

2024-11-04 Thread Ilpo Järvinen
On Sun, 3 Nov 2024, Thomas Weißschuh wrote: > The is_bin_visible() callbacks should not modify the struct > bin_attribute passed as argument. > Enforce this by marking the argument as const. > > As there are not many callback implementers perform this change > throughout the tree at once. > > Si

Re: [PATCH v3 3/5] PCI: Allow IOV resources to be resized in pci_resize_resource

2024-10-10 Thread Ilpo Järvinen
On Thu, 10 Oct 2024, Michał Winiarski wrote: > Similar to regular resizable BAR, VF BAR can also be resized. > The structures are very similar, which means we can reuse most of the > implementation. See PCIe r4.0, sec 9.3.7.4. > > Signed-off-by: Michał Winiarski > --- > drivers/pci/iov.c

Re: [PATCH v3 1/5] PCI/IOV: Restore VF resizable BAR state after reset

2024-10-10 Thread Ilpo Järvinen
return; > + > + pci_read_config_dword(dev, pos + PCI_REBAR_CTRL, &ctrl); > + nbars = FIELD_GET(PCI_REBAR_CTRL_NBAR_MASK, ctrl); > + > + for (i = 0; i < nbars; i++, pos += 8) { > + int bar_idx, size; > + > + pci_read_config_dwor

Re: [PATCH v3 2/5] PCI: Add a helper to identify IOV resources

2024-10-10 Thread Ilpo Järvinen
add_align = max(pci_resource_alignment(dev, r), > add_align); > r->end = r->start - 1; > add_to_list(realloc_head, dev, r, r_size, 0 /* > Don't care */); > children_add_size += r_size; >

Re: [RFC PATCH v4 1/1] platform/x86/tuxedo: Add virtual LampArray for TUXEDO NB04 devices

2024-10-04 Thread Ilpo Järvinen
On Fri, 4 Oct 2024, Werner Sembach wrote: > Am 03.10.24 um 12:54 schrieb Ilpo Järvinen: > > On Wed, 2 Oct 2024, Werner Sembach wrote: > > > Am 02.10.24 um 11:52 schrieb Ilpo Järvinen: > > > > On Tue, 1 Oct 2024, Werner Sembach wrote: > > > > > > &

Re: [RFC PATCH v4 1/1] platform/x86/tuxedo: Add virtual LampArray for TUXEDO NB04 devices

2024-10-03 Thread Ilpo Järvinen
On Wed, 2 Oct 2024, Werner Sembach wrote: > Am 02.10.24 um 11:52 schrieb Ilpo Järvinen: > > On Tue, 1 Oct 2024, Werner Sembach wrote: > > > > > The TUXEDO Sirius 16 Gen1 and TUXEDO Sirius 16 Gen2 devices have a per-key > > > controllable RGB keyboard back

Re: [RFC PATCH v4 1/1] platform/x86/tuxedo: Add virtual LampArray for TUXEDO NB04 devices

2024-10-02 Thread Ilpo Järvinen
On Wed, 2 Oct 2024, Pavel Machek wrote: > Hi! > > > > +static struct wmi_driver tuxedo_nb04_wmi_ab_driver = { > > > + .driver = { > > > + .name = "tuxedo_nb04_wmi_ab", > > > + .probe_type = PROBE_PREFER_ASYNCHRONOUS, > > > + }, > > > + .id_table = tuxedo_nb04_wmi_ab_device_ids, >

Re: [RFC PATCH v4 1/1] platform/x86/tuxedo: Add virtual LampArray for TUXEDO NB04 devices

2024-10-02 Thread Ilpo Järvinen
On Tue, 1 Oct 2024, Werner Sembach wrote: > The TUXEDO Sirius 16 Gen1 and TUXEDO Sirius 16 Gen2 devices have a per-key > controllable RGB keyboard backlight. The firmware API for it is implemented > via WMI. > > To make the backlight userspace configurable this driver emulates a > LampArray HID d

Re: [PATCH v2 2/3] PCI: Allow extending VF BAR within original resource boundary

2024-09-20 Thread Ilpo Järvinen
On Fri, 20 Sep 2024, Michał Winiarski wrote: > VF MMIO resource reservation, either created by system firmware and > inherited by Linux PCI subsystem or created by the subsystem itself, > contains enough space to fit the BAR of all SR-IOV Virtual Functions > that can potentially be created (total

Re: [PATCH v7 09/13] PCI: Give pcim_set_mwi() its own devres callback

2024-06-13 Thread Ilpo Järvinen
On Wed, 5 Jun 2024, Philipp Stanner wrote: > Managing pci_set_mwi() with devres can easily be done with its own > callback, without the necessity to store any state about it in a > device-related struct. > > Remove the MWI state from struct pci_devres. > Give pcim_set_mwi() a separate devres-call

Re: [PATCH v7 10/13] PCI: Give pci(m)_intx its own devres callback

2024-06-13 Thread Ilpo Järvinen
On Wed, 5 Jun 2024, Philipp Stanner wrote: > pci_intx() is one of the functions that have "hybrid mode" (i.e., > sometimes managed, sometimes not). Providing a separate pcim_intx() > function with its own device resource and cleanup callback allows for > removing further large parts of the legacy

Re: [PATCH v7 01/13] PCI: Add and use devres helper for bit masks

2024-06-13 Thread Ilpo Järvinen
On Wed, 5 Jun 2024, Philipp Stanner wrote: > The current derves implementation uses manual shift operations to check > whether a bit in a mask is set. The code can be made more readable by > writing a small helper function for that. > > Implement mask_contains_bar() and use it where applicable. >

Re: [PATCH v7 03/13] PCI: Reimplement plural devres functions

2024-06-13 Thread Ilpo Järvinen
On Wed, 5 Jun 2024, Philipp Stanner wrote: > When the original PCI devres API was implemented, priority was given to > the creation of a set of "plural functions" such as > pcim_request_regions(). These functions have bit masks as parameters to > specify which BARs shall get mapped. Most users, ho

Re: [PATCH] kernel/resource: optimize find_next_iomem_res

2024-06-03 Thread Ilpo Järvinen
On Fri, 31 May 2024, Chia-I Wu wrote: > On Fri, May 31, 2024 at 1:57 AM Andy Shevchenko > > wrote: > On Thu, May 30, 2024 at 10:36:57PM -0700, Chia-I Wu wrote: > > We can skip children resources when the parent resource does not cover > > the range. > > > > This shou

Re: [PATCH] kernel/resource: optimize find_next_iomem_res

2024-06-03 Thread Ilpo Järvinen
On Sun, 2 Jun 2024, Andy Shevchenko wrote: > On Fri, May 31, 2024 at 02:31:45PM -0700, Chia-I Wu wrote: > > On Fri, May 31, 2024 at 1:57 AM Andy Shevchenko < > > andriy.shevche...@linux.intel.com> wrote: > > > On Thu, May 30, 2024 at 10:36:57PM -0700, Chia-I Wu wrote: > > ... > > > > P.S> I'm no

Re: [PATCH 3/3] RDMA/hfi1: Use RMW accessors for changing LNKCTL2

2024-05-03 Thread Ilpo Järvinen
On Thu, 15 Feb 2024, Ilpo Järvinen wrote: > Convert open coded RMW accesses for LNKCTL2 to use > pcie_capability_clear_and_set_word() which makes its easier to > understand what the code tries to do. > > LNKCTL2 is not really owned by any driver because it is a collection of >

Re: [PATCH 06/10] drm: move i915_drm.h under include/drm/intel

2024-04-10 Thread Ilpo Järvinen
On Wed, 10 Apr 2024, Jani Nikula wrote: > Clean up the top level include/drm directory by grouping all the Intel > specific files under a common subdirectory. > > Cc: Daniel Vetter > Cc: Dave Airlie > Cc: Lucas De Marchi > Cc: Bjorn Helgaas > Cc: Hans de Goede >

RE: [PATCH 1/3] drm/radeon: Use RMW accessors for changing LNKCTL2

2024-02-16 Thread Ilpo Järvinen
On Thu, 15 Feb 2024, Deucher, Alexander wrote: > [Public] > > > -Original Message- > > From: Ilpo Järvinen > > Sent: Thursday, February 15, 2024 8:32 AM > > To: Deucher, Alexander ; amd- > > g...@lists.freedesktop.org; Daniel Vetter ; David Airli

[PATCH 3/3] RDMA/hfi1: Use RMW accessors for changing LNKCTL2

2024-02-15 Thread Ilpo Järvinen
have support for proper locking for a selected set of registers (LNKCTL2 is not yet among them but likely will be in the future) to avoid losing concurrent updates. Suggested-by: Lukas Wunner Signed-off-by: Ilpo Järvinen Reviewed-by: Dean Luick --- drivers/infiniband/hw/hfi1/pcie.c | 30

[PATCH 2/3] drm/amdgpu: Use RMW accessors for changing LNKCTL2

2024-02-15 Thread Ilpo Järvinen
have support for proper locking for a selected set of registers (LNKCTL2 is not yet among them but likely will be in the future) to avoid losing concurrent updates. Suggested-by: Lukas Wunner Signed-off-by: Ilpo Järvinen --- drivers/gpu/drm/amd/amdgpu/cik.c | 41

[PATCH 1/3] drm/radeon: Use RMW accessors for changing LNKCTL2

2024-02-15 Thread Ilpo Järvinen
have support for proper locking for a selected set of registers (LNKCTL2 is not yet among them but likely will be in the future) to avoid losing concurrent updates. Suggested-by: Lukas Wunner Signed-off-by: Ilpo Järvinen --- drivers/gpu/drm/radeon/cik.c | 40

[PATCH 0/3] PCI LNKCTL2 RMW Accessor Cleanup

2024-02-15 Thread Ilpo Järvinen
separately to reduce the size of the BW controller series. [1] https://lore.kernel.org/linux-pci/20240105112547.7301-1-ilpo.jarvi...@linux.intel.com/ Ilpo Järvinen (3): drm/radeon: Use RMW accessors for changing LNKCTL2 drm/amdgpu: Use RMW accessors for changing LNKCTL2 RDMA/hfi1: Use RMW

[PATCH v4 3/8] drm/amdgpu: Use RMW accessors for changing LNKCTL2

2024-01-05 Thread Ilpo Järvinen
change is also useful as a cleanup. Suggested-by: Lukas Wunner Signed-off-by: Ilpo Järvinen --- drivers/gpu/drm/amd/amdgpu/cik.c | 41 drivers/gpu/drm/amd/amdgpu/si.c | 41 2 files changed, 30 insertions(+), 52 deletions(-) di

[PATCH v4 2/8] drm/radeon: Use RMW accessors for changing LNKCTL2

2024-01-05 Thread Ilpo Järvinen
change is also useful as a cleanup. Suggested-by: Lukas Wunner Signed-off-by: Ilpo Järvinen --- drivers/gpu/drm/radeon/cik.c | 40 ++-- drivers/gpu/drm/radeon/si.c | 40 ++-- 2 files changed, 30 insertions(+), 50 deletions(-) di

Re: [PATCH v3 6/7] PCI: Split up some logic in pcie_bandwidth_available() to separate function

2023-11-16 Thread Ilpo Järvinen
On Tue, 14 Nov 2023, Mario Limonciello wrote: > The logic to calculate bandwidth limits may be used at multiple call sites > so split it up into its own static function instead. > > No intended functional changes. > > Suggested-by: Ilpo Järvinen > Signed-off-by: Mario Li

Re: [PATCH v3 3/7] PCI: Drop pci_is_thunderbolt_attached()

2023-11-16 Thread Ilpo Järvinen
; #if defined(CONFIG_PCIEPORTBUS) || defined(CONFIG_EEH) > void pci_uevent_ers(struct pci_dev *pdev, enum pci_ers_result err_type); > #endif > Reviewed-by: Ilpo Järvinen -- i.

Re: [PATCH v3 1/7] drm/nouveau: Switch from pci_is_thunderbolt_attached() to dev_is_removable()

2023-11-16 Thread Ilpo Järvinen
On Tue, 14 Nov 2023, Mario Limonciello wrote: > pci_is_thunderbolt_attached() looks at the hierarchy of the PCIe device > to determine if any bridge along the way has the is_thunderbolt bit set. > This bit will only be set when one of the devices in the hierarchy is an > Intel Thunderbolt device.

Re: [PATCH v3 4/7] PCI: pciehp: Move check for is_thunderbolt into a quirk

2023-11-16 Thread Ilpo Järvinen
4fc3060 100644 > --- a/include/linux/pci.h > +++ b/include/linux/pci.h > @@ -441,6 +441,7 @@ struct pci_dev { > unsigned intis_hotplug_bridge:1; > unsigned intshpc_managed:1; /* SHPC owned by shpchp */ > unsigned intis_thunderbolt:1; /* Thunderbolt controller */ > + unsigned intno_command_complete:1; /* No command completion */ > /* >* Devices marked being untrusted are the ones that can potentially >* execute DMA attacks and similar. They are typically connected > Reviewed-by: Ilpo Järvinen -- i.

Re: [PATCH v2 8/9] PCI: Exclude PCIe ports used for tunneling in pcie_bandwidth_available()

2023-11-06 Thread Ilpo Järvinen
On Fri, 3 Nov 2023, Mario Limonciello wrote: > The USB4 spec specifies that PCIe ports that are used for tunneling > PCIe traffic over USB4 fabric will be hardcoded to advertise 2.5GT/s and > behave as a PCIe Gen1 device. The actual performance of these ports is > controlled by the fabric implemen

Re: [PATCH v2 5/9] PCI: pciehp: Move check for is_thunderbolt into a quirk

2023-11-06 Thread Ilpo Järvinen
On Fri, 3 Nov 2023, Mario Limonciello wrote: > commit 493fb50e958c ("PCI: pciehp: Assume NoCompl+ for Thunderbolt > ports") added a check into pciehp code to explicitly set NoCompl+ > for all Intel Thunderbolt controllers, including those that don't > need it. > > This overloaded the purpose of t

Re: [PATCH v2 3/9] PCI: Drop pci_is_thunderbolt_attached()

2023-11-06 Thread Ilpo Järvinen
On Fri, 3 Nov 2023, Mario Limonciello wrote: > All callers have switched to dev_is_removable() for detecting > hotpluggable PCIe devices. > > Signed-off-by: Mario Limonciello > --- > include/linux/pci.h | 22 -- > 1 file changed, 22 deletions(-) > > diff --git a/include/lin

Re: [PATCH v2 2/9] drm/radeon: Switch from pci_is_thunderbolt_attached() to dev_is_removable()

2023-11-06 Thread Ilpo Järvinen
On Fri, 3 Nov 2023, Mario Limonciello wrote: > pci_is_thunderbolt_attached() only works for Intel TBT devices. Switch to > using dev_is_removable() to be able to detect USB4 devices as well. Same here as with 1/9. -- i. > Signed-off-by: Mario Limonciello > --- > drivers/gpu/drm/radeon/radeo

Re: [PATCH v2 1/9] drm/nouveau: Switch from pci_is_thunderbolt_attached() to dev_is_removable()

2023-11-06 Thread Ilpo Järvinen
On Fri, 3 Nov 2023, Mario Limonciello wrote: > pci_is_thunderbolt_attached() only works for Intel TBT devices. Switch to > using dev_is_removable() to be able to detect USB4 devices as well. Please extend this with more details. I had to lookup the TBT change to be able to make any guess why you

Re: [PATCH v4 11/17] platform/x86/amd/pmf: Add capability to sideload of policy binary

2023-10-18 Thread Ilpo Järvinen
On Wed, 18 Oct 2023, Shyam Sundar S K wrote: > A policy binary is OS agnostic, and the same policies are expected to work > across the OSes. At times it becomes difficult to debug when the policies > inside the policy binaries starts to misbehave. Add a way to sideload such > policies independent

Re: [PATCH v4 12/17] platform/x86/amd/pmf: dump policy binary data

2023-10-18 Thread Ilpo Järvinen
t_bios_buffer(struct amd_pmf_dev > *dev) > > memcpy(dev->policy_buf, dev->policy_base, dev->policy_sz); > > + amd_pmf_hex_dump_pb(dev); > if (pb_side_load) > amd_pmf_open_pb(dev, dev->dbgfs_dir); Reviewed-by: Ilpo Järvinen -- i.

Re: [PATCH v4 13/17] platform/x86/amd/pmf: Add PMF-AMDGPU get interface

2023-10-18 Thread Ilpo Järvinen
On Wed, 18 Oct 2023, Shyam Sundar S K wrote: > On 10/18/2023 2:50 PM, Ilpo Järvinen wrote: > > On Wed, 18 Oct 2023, Shyam Sundar S K wrote: > > > >> In order to provide GPU inputs to TA for the Smart PC solution to work, we > >> need to have interface between the

Re: [PATCH v4 13/17] platform/x86/amd/pmf: Add PMF-AMDGPU get interface

2023-10-18 Thread Ilpo Järvinen
On Wed, 18 Oct 2023, Shyam Sundar S K wrote: > In order to provide GPU inputs to TA for the Smart PC solution to work, we > need to have interface between the PMF driver and the AMDGPU driver. > > Add the initial code path for get interface from AMDGPU. > > Co-developed-by: Mario Limonciello >

Re: [PATCH v4 10/17] platform/x86/amd/pmf: Add facility to dump TA inputs

2023-10-18 Thread Ilpo Järvinen
On Wed, 18 Oct 2023, Shyam Sundar S K wrote: > PMF driver sends constant inputs to TA which its gets via the other > subsystems in the kernel. To debug certain TA issues knowing what inputs > being sent to TA becomes critical. Add debug facility to the driver which > can isolate Smart PC and TA re

Re: [PATCH v4 16/17] platform/x86/amd/pmf: Add PMF-AMDSFH interface for HPD

2023-10-18 Thread Ilpo Järvinen
On Wed, 18 Oct 2023, Shyam Sundar S K wrote: > From: Basavaraj Natikar > > AMDSFH has information about the User presence information via the Human > Presence Detection (HPD) sensor which is part of the AMD sensor fusion hub. > Add PMF and AMDSFH interface to get this information. > > Co-develo

Re: [PATCH v4 15/17] HID: amd_sfh: rename float_to_int() to amd_sfh_float_to_int()

2023-10-18 Thread Ilpo Järvinen
break; > diff --git a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_interface.h > b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_interface.h > index 9d31d5b510eb..78e22850417a 100644 > --- a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_interface.h > +++ b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_interface.h > @@ -151,4 +151,5 @@ struct hpd_status { > > void sfh_interface_init(struct amd_mp2_dev *mp2); > void amd_sfh1_1_set_desc_ops(struct amd_mp2_ops *mp2_ops); > +int amd_sfh_float_to_int(u32 flt32_val); > #endif Reviewed-by: Ilpo Järvinen -- i.

Re: [PATCH v3 06/16] platform/x86/amd/pmf: Add support to get inputs from other subsystems

2023-10-13 Thread Ilpo Järvinen
On Tue, 10 Oct 2023, Shyam Sundar S K wrote: > PMF driver sends changing inputs from each subystem to TA for evaluating > the conditions in the policy binary. > > Add initial support of plumbing in the PMF driver for Smart PC to get > information from other subsystems in the kernel. > > Signed-o

Re: [PATCH v3 11/16] platform/x86/amd/pmf: dump policy binary data

2023-10-10 Thread Ilpo Järvinen
On Tue, 10 Oct 2023, Shyam Sundar S K wrote: > On 10/10/2023 6:38 PM, Ilpo Järvinen wrote: > > On Tue, 10 Oct 2023, Shyam Sundar S K wrote: > > > >> Sometimes policy binary retrieved from the BIOS maybe incorrect that can > >> end up in failing to ena

Re: [PATCH v3 11/16] platform/x86/amd/pmf: dump policy binary data

2023-10-10 Thread Ilpo Järvinen
On Tue, 10 Oct 2023, Shyam Sundar S K wrote: > Sometimes policy binary retrieved from the BIOS maybe incorrect that can > end up in failing to enable the Smart PC solution feature. > > Use print_hex_dump_debug() to dump the policy binary in hex, so that we > debug the issues related to the binary

Re: [PATCH v2 12/16] platform/x86/amd/pmf: Add PMF-AMDGPU get interface

2023-10-09 Thread Ilpo Järvinen
On Mon, 9 Oct 2023, Shyam Sundar S K wrote: > On 10/4/2023 6:19 PM, Ilpo Järvinen wrote: > > On Sat, 30 Sep 2023, Shyam Sundar S K wrote: > > > >> In order to provide GPU inputs to TA for the Smart PC solution to work, we > >> need to have interface between the

Re: [PATCH v2 04/16] platform/x86/amd/pmf: Add support for PMF Policy Binary

2023-10-09 Thread Ilpo Järvinen
On Mon, 9 Oct 2023, Shyam Sundar S K wrote: > On 10/4/2023 5:30 PM, Ilpo Järvinen wrote: > > On Sat, 30 Sep 2023, Shyam Sundar S K wrote: > > > >> PMF Policy binary is a encrypted and signed binary that will be part > >> of the BIOS. PMF driver via the ACPI inter

Re: [PATCH v2 01/16] platform/x86/amd/pmf: Add PMF TEE interface

2023-10-09 Thread Ilpo Järvinen
On Mon, 9 Oct 2023, Shyam Sundar S K wrote: > > > On 10/4/2023 4:20 PM, Ilpo Järvinen wrote: > > On Sat, 30 Sep 2023, Shyam Sundar S K wrote: > > > >> AMD PMF driver loads the PMF TA (Trusted Application) into the AMD > >> ASP's (AMD Security P

Re: [PATCH v2 06/16] platform/x86/amd/pmf: Add support to get inputs from other subsystems

2023-10-09 Thread Ilpo Järvinen
On Mon, 9 Oct 2023, Shyam Sundar S K wrote: > On 10/4/2023 5:44 PM, Ilpo Järvinen wrote: > > On Sat, 30 Sep 2023, Shyam Sundar S K wrote: > > > >> PMF driver sends changing inputs from each subystem to TA for evaluating > >> the conditions in the policy binary.

Re: [PATCH v2 12/16] platform/x86/amd/pmf: Add PMF-AMDGPU get interface

2023-10-04 Thread Ilpo Järvinen
On Sat, 30 Sep 2023, Shyam Sundar S K wrote: > In order to provide GPU inputs to TA for the Smart PC solution to work, we > need to have interface between the PMF driver and the AMDGPU driver. > > Add the initial code path for get interface from AMDGPU. > > Co-developed-by: Mario Limonciello >

Re: [PATCH v2 11/16] platform/x86/amd/pmf: dump policy binary data

2023-10-04 Thread Ilpo Järvinen
On Sat, 30 Sep 2023, Shyam Sundar S K wrote: > Sometimes policy binary retrieved from the BIOS maybe incorrect that can > end up in failing to enable the Smart PC solution feature. > > Use print_hex_dump_debug() to dump the policy binary in hex, so that we > debug the issues related to the binary

Re: [PATCH v2 09/16] platform/x86/amd/pmf: Add facility to dump TA inputs

2023-10-04 Thread Ilpo Järvinen
On Sat, 30 Sep 2023, Shyam Sundar S K wrote: > PMF driver sends constant inputs to TA which its gets via the other > subsystems in the kernel. To debug certain TA issues knowing what inputs > being sent to TA becomes critical. Add debug facility to the driver which > can isolate Smart PC and TA re

Re: [PATCH v2 08/16] platform/x86/amd/pmf: Add support to update system state

2023-10-04 Thread Ilpo Järvinen
On Sat, 30 Sep 2023, Shyam Sundar S K wrote: > PMF driver based on the output actions from the TA can request to update > the system states like entering s0i3, lock screen etc. by generating > an uevent. Based on the udev rules set in the userspace the event id > matching the uevent shall get upda

Re: [PATCH v2 06/16] platform/x86/amd/pmf: Add support to get inputs from other subsystems

2023-10-04 Thread Ilpo Järvinen
On Sat, 30 Sep 2023, Shyam Sundar S K wrote: > PMF driver sends changing inputs from each subystem to TA for evaluating > the conditions in the policy binary. > > Add initial support of plumbing in the PMF driver for Smart PC to get > information from other subsystems in the kernel. > > Signed-o

Re: [PATCH v2 02/16] platform/x86/amd/pmf: Add support PMF-TA interaction

2023-10-04 Thread Ilpo Järvinen
On Sat, 30 Sep 2023, Shyam Sundar S K wrote: > PMF TA (Trusted Application) loads via the TEE environment into the > AMD ASP. > > PMF-TA supports two commands: > 1) Init: Initialize the TA with the PMF Smart PC policy binary and > start the policy engine. A policy is a combination of inputs and >

Re: [PATCH v2 04/16] platform/x86/amd/pmf: Add support for PMF Policy Binary

2023-10-04 Thread Ilpo Järvinen
On Sat, 30 Sep 2023, Shyam Sundar S K wrote: > PMF Policy binary is a encrypted and signed binary that will be part > of the BIOS. PMF driver via the ACPI interface checks the existence > of Smart PC bit. If the advertised bit is found, PMF driver walks > the acpi namespace to find out the policy

Re: [PATCH v2 01/16] platform/x86/amd/pmf: Add PMF TEE interface

2023-10-04 Thread Ilpo Järvinen
On Sat, 30 Sep 2023, Shyam Sundar S K wrote: > AMD PMF driver loads the PMF TA (Trusted Application) into the AMD > ASP's (AMD Security Processor) TEE (Trusted Execution Environment). > > PMF Trusted Application is a secured firmware placed under > /lib/firmware/amdtee gets loaded only when the T

Re: [PATCH v2 03/16] platform/x86/amd/pmf: Change return type of amd_pmf_set_dram_addr()

2023-10-04 Thread Ilpo Järvinen
On Sat, 30 Sep 2023, Shyam Sundar S K wrote: > In the current code, the metrics table information was required only > for auto-mode or CnQF at a given time. Hence keeping the return type > of amd_pmf_set_dram_addr() as static made sense. > > But with the addition of Smart PC builder feature, the

Re: [PATCH v2 02/16] platform/x86/amd/pmf: Add support PMF-TA interaction

2023-10-04 Thread Ilpo Järvinen
On Sat, 30 Sep 2023, Shyam Sundar S K wrote: > PMF TA (Trusted Application) loads via the TEE environment into the > AMD ASP. > > PMF-TA supports two commands: > 1) Init: Initialize the TA with the PMF Smart PC policy binary and > start the policy engine. A policy is a combination of inputs and >

Re: [PATCH v2 01/16] platform/x86/amd/pmf: Add PMF TEE interface

2023-10-04 Thread Ilpo Järvinen
On Sat, 30 Sep 2023, Shyam Sundar S K wrote: > AMD PMF driver loads the PMF TA (Trusted Application) into the AMD > ASP's (AMD Security Processor) TEE (Trusted Execution Environment). > > PMF Trusted Application is a secured firmware placed under > /lib/firmware/amdtee gets loaded only when the T

Re: [PATCH 06/15] platform/x86/amd/pmf: Add support to get inputs from other subsystems

2023-10-02 Thread Ilpo Järvinen
On Sat, 30 Sep 2023, Shyam Sundar S K wrote: > On 9/26/2023 10:38 PM, Ilpo Järvinen wrote: > > On Fri, 22 Sep 2023, Shyam Sundar S K wrote: > > > >> PMF driver sends changing inputs from each subystem to TA for evaluating > >> the conditions in the policy binary.

[PATCH v3 03/10] drm/amdgpu: Use RMW accessors for changing LNKCTL2

2023-09-29 Thread Ilpo Järvinen
change is also useful as a cleanup. Suggested-by: Lukas Wunner Signed-off-by: Ilpo Järvinen --- drivers/gpu/drm/amd/amdgpu/cik.c | 41 drivers/gpu/drm/amd/amdgpu/si.c | 41 2 files changed, 30 insertions(+), 52 deletions(-) di

[PATCH v3 02/10] drm/radeon: Use RMW accessors for changing LNKCTL2

2023-09-29 Thread Ilpo Järvinen
change is also useful as a cleanup. Suggested-by: Lukas Wunner Signed-off-by: Ilpo Järvinen --- drivers/gpu/drm/radeon/cik.c | 40 ++-- drivers/gpu/drm/radeon/si.c | 40 ++-- 2 files changed, 30 insertions(+), 50 deletions(-) di

Re: [PATCH 13/15] platform/x86/amd/pmf: Add PMF-AMDGPU set interface

2023-09-27 Thread Ilpo Järvinen
On Fri, 22 Sep 2023, Shyam Sundar S K wrote: > For the Smart PC Solution to fully work, it has to enact to the actions > coming from TA. Add the initial code path for set interface to AMDGPU. > > Co-developed-by: Mario Limonciello > Signed-off-by: Mario Limonciello > Signed-off-by: Shyam Sundar

Re: [PATCH 15/15] platform/x86/amd/pmf: Add PMF-AMDSFH interface for ALS

2023-09-27 Thread Ilpo Järvinen
On Fri, 22 Sep 2023, Shyam Sundar S K wrote: > From: Basavaraj Natikar > > AMDSFH has information about the Ambient light via the Ambient > Light Sensor (ALS) which is part of the AMD sensor fusion hub. > Add PMF and AMDSFH interface to get this information. > > Co-developed-by: Shyam Sundar S

Re: [PATCH 14/15] platform/x86/amd/pmf: Add PMF-AMDSFH interface for HPD

2023-09-27 Thread Ilpo Järvinen
On Fri, 22 Sep 2023, Shyam Sundar S K wrote: > From: Basavaraj Natikar > > AMDSFH has information about the User presence information via the Human > Presence Detection (HPD) sensor which is part of the AMD sensor fusion hub. > Add PMF and AMDSFH interface to get this information. > > Co-develo

Re: [PATCH 12/15] platform/x86/amd/pmf: Add PMF-AMDGPU get interface

2023-09-27 Thread Ilpo Järvinen
On Fri, 22 Sep 2023, Shyam Sundar S K wrote: > In order to provide GPU inputs to TA for the Smart PC solution to work, we > need to have interface between the PMF driver and the AMDGPU driver. > > Add the initial code path for get interface from AMDGPU. > > Co-developed-by: Mario Limonciello >

Re: [PATCH 10/15] platform/x86/amd/pmf: Add capability to sideload of policy binary

2023-09-27 Thread Ilpo Järvinen
On Fri, 22 Sep 2023, Shyam Sundar S K wrote: > A policy binary is OS agnostic, and the same policies are expected to work > across the OSes. At times it becomes difficult to debug when the policies > inside the policy binaries starts to misbehave. Add a way to sideload such > policies independent

Re: [PATCH 09/15] platform/x86/amd/pmf: Add facility to dump TA inputs

2023-09-27 Thread Ilpo Järvinen
On Fri, 22 Sep 2023, Shyam Sundar S K wrote: > PMF driver sends constant inputs to TA which its gets via the other > subsystems in the kernel. To debug certain TA issues knowing what inputs > being sent to TA becomes critical. Add debug facility to the driver which > can isolate Smart PC and TA re

Re: [PATCH 08/15] platform/x86/amd/pmf: Add support to update system state

2023-09-27 Thread Ilpo Järvinen
On Fri, 22 Sep 2023, Shyam Sundar S K wrote: > PMF driver based on the output actions from the TA can request to update > the system states like entering s0i3, lock screen etc. by generating > an uevent. Based on the udev rules set in the userspace the event id > matching the uevent shall get upda

Re: [PATCH 07/15] platform/x86/amd/pmf: Add support update p3t limit

2023-09-27 Thread Ilpo Järvinen
On Fri, 22 Sep 2023, Shyam Sundar S K wrote: > P3T (Peak Package Power Limit) is a metric within the SMU controller > that can influence the power limits. Add support from the driver > to update P3T limits accordingly. > > Reviewed-by: Mario Limonciello > Signed-off-by: Shyam Sundar S K > --- >

Re: [PATCH 04/15] platform/x86/amd/pmf: Add support for PMF Policy Binary

2023-09-27 Thread Ilpo Järvinen
On Fri, 22 Sep 2023, Shyam Sundar S K wrote: > PMF Policy binary is a encrypted and signed binary that will be part > of the BIOS. PMF driver via the ACPI interface checks the existence > of Smart PC bit. If the advertised bit is found, PMF driver walks > the acpi namespace to find out the policy

Re: [PATCH 06/15] platform/x86/amd/pmf: Add support to get inputs from other subsystems

2023-09-26 Thread Ilpo Järvinen
On Fri, 22 Sep 2023, Shyam Sundar S K wrote: > PMF driver sends changing inputs from each subystem to TA for evaluating > the conditions in the policy binary. > > Add initial support of plumbing in the PMF driver for Smart PC to get > information from other subsystems in the kernel. > > Signed-o

Re: [PATCH 04/15] platform/x86/amd/pmf: Add support for PMF Policy Binary

2023-09-26 Thread Ilpo Järvinen
On Fri, 22 Sep 2023, Shyam Sundar S K wrote: > PMF Policy binary is a encrypted and signed binary that will be part > of the BIOS. PMF driver via the ACPI interface checks the existence > of Smart PC bit. If the advertised bit is found, PMF driver walks > the acpi namespace to find out the policy

  1   2   >