Igt-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Francois Dugast <francois.dugast@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: "Satyanarayana K V P" <satyanarayana.k.v.p@intel.com>,
	igt-dev@lists.freedesktop.org,
	"Michał Wajdeczko" <michal.wajdeczko@intel.com>
Subject: Re: [PATCH i-g-t v3 1/6] lib/igt_sysfs: Add support for device unbinding
Date: Fri, 14 Mar 2025 09:32:16 +0100	[thread overview]
Message-ID: <Z9PpgiF5hdk76tQR@fdugast-desk> (raw)
In-Reply-To: <fvh6tqhtox7iw7lov2cok6575fprql7d4aa5crpt3yxktycfcf@ibfjqf466jmp>

Hi,

On Wed, Mar 12, 2025 at 10:25:15PM -0500, Lucas De Marchi wrote:
> On Thu, Mar 06, 2025 at 03:40:36PM +0530, Satyanarayana K V P wrote:
> > It does not harm anything when we try to unbind a device which
> > is already unbinded. We do not want to throw assertion when
> > the device is already unbinded.
> > 
> > Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
> > Cc: Michał Wajdeczko <michal.wajdeczko@intel.com>
> > Cc: Francois Dugast <francois.dugast@intel.com>
> > Reviewed-by: Francois Dugast <francois.dugast@intel.com>
> > ---
> > lib/igt_sysfs.c | 4 ++++
> > lib/igt_sysfs.h | 1 +
> > 2 files changed, 5 insertions(+)
> > 
> > diff --git a/lib/igt_sysfs.c b/lib/igt_sysfs.c
> > index 2e4c2ee63..3fffaf96b 100644
> > --- a/lib/igt_sysfs.c
> > +++ b/lib/igt_sysfs.c
> > @@ -1509,6 +1509,10 @@ int xe_sysfs_driver_do(int xe_device, char pci_slot[], enum xe_sysfs_driver_acti
> > 		igt_assert(igt_sysfs_set(sysfs, "unbind", pci_slot));
> > 		close(sysfs);
> > 		break;
> > +	case XE_SYSFS_DRIVER_TRY_UNBIND:
> 
> oh no, this function uses the wrong design,

Yes, my bad.

> let's not make it worse.
> xe_sysfs_driver_do() should really be dropped and we should use the
> proper functions.

Those would be igt_kmod_unbind() and a new function igt_kmod_bind()
which would be allowed to fail, that is with no systematic assert
on igt_sysfs_set() as it should fail in the case of fault injection.

> 
> It's also in the wrong lib layer. igt_sysfs is for supporting sysfs
> things like opening, writing, mapping from a device to the right
> directory, setting an value, etc. We shouldn't do to do arbitrary thing
> **using** sysfs.

Another reason to completely get rid of xe_sysfs_driver_do().

> 
> Finally, when we want to unbind we shouldn't really pass an fd. The
> caller has no idea if the library function will close it or not. That
> triggers several different paths in the kernel as userspace holds or not
> an fd open.
> 
> Please do not more to this function. We already have igt_kmod_unbind(),
> we could have igt_kmod_unbind_device(). As we could have dedicated
> functions in the right layer for all the other actions here.
> 
> Lucas De Marchi

  reply	other threads:[~2025-03-14  8:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-06 10:10 [PATCH i-g-t v3 0/6] tests/intel/xe_fault_injection: Inject errors during xe_guc_ct_send_recv() xe_guc_mmio_send_recv() Satyanarayana K V P
2025-03-06 10:10 ` [PATCH i-g-t v3 1/6] lib/igt_sysfs: Add support for device unbinding Satyanarayana K V P
2025-03-13  3:25   ` Lucas De Marchi
2025-03-14  8:32     ` Francois Dugast [this message]
2025-03-06 10:10 ` [PATCH i-g-t v3 2/6] tests/intel/xe_fault_injection: Make setup_injection_fault() programmable Satyanarayana K V P
2025-03-13  3:27   ` Lucas De Marchi
2025-03-06 10:10 ` [PATCH i-g-t v3 3/6] tests/intel/xe_fault_injection: Add helper to start injecting fault after x iterations Satyanarayana K V P
2025-03-13  3:15   ` Lucas De Marchi
2025-03-06 10:10 ` [PATCH i-g-t v3 4/6] tests/intel/xe_fault_injection: Inject errors during xe_guc_ct_send_recv & xe_guc_mmio_send_recv Satyanarayana K V P
2025-03-13  4:05   ` Lucas De Marchi
2025-03-06 10:10 ` [PATCH i-g-t v3 5/6] tests/intel/xe_fault_injection: Try to unbind the device after error injection Satyanarayana K V P
2025-03-06 10:10 ` [PATCH i-g-t v3 6/6] tests/intel/xe_fault_injection: Do not assert for probe_guc_fail_* functions Satyanarayana K V P
2025-03-07  1:27 ` ✓ i915.CI.BAT: success for tests/intel/xe_fault_injection: Inject errors during xe_guc_ct_send_recv() xe_guc_mmio_send_recv() (rev3) Patchwork
2025-03-07  1:54 ` ✓ Xe.CI.BAT: " Patchwork
2025-03-07  3:43 ` ✓ i915.CI.Full: " Patchwork
2025-03-07 10:51 ` ✗ Xe.CI.Full: failure " Patchwork

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=Z9PpgiF5hdk76tQR@fdugast-desk \
    --to=francois.dugast@intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=michal.wajdeczko@intel.com \
    --cc=satyanarayana.k.v.p@intel.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