Re: Kernel module that shuts down the device

From: Greg KH <greg@kroah.com>
To: Drew Abbott <abbotta4@gmail.com>
Cc: kernelnewbies@kernelnewbies.org
Subject: Re: Kernel module that shuts down the device
Date: Tue, 9 Nov 2021 07:23:58 +0100	[thread overview]
Message-ID: <YYoT/m0qJKueYNYU@kroah.com> (raw)
In-Reply-To: <CALY-g84_two85_kcLOfwdFktSJB5_8c8=aJjbVqtvnLNm7+-yg@mail.gmail.com>

On Mon, Nov 08, 2021 at 02:53:37PM -0600, Drew Abbott wrote:
> > There's a whole bunch of ways to schedule work in the kernel, it doesn't
> have to be
> > a heartbeat function.
> >
> > Plenty of drivers are split into IRQ and non-IRQ parts (sometimes called
> the top and
> > bottom parts of the driver).  See how they get info from the IRQ part to
> the non-IRQ part.
> 
> I saw that this driver and others use workqueues to run longer functions
> outside of the irq handlers in the process context, so I tried scheduling a
> simple work struct that calls kernel_power_off() with this new patch:
> https://github.com/Abbotta4/linux/commit/008a720d9ffc31d5b60e0ca36f2aad0a04d50f0a
> after reading up on workqueues a bit here:
> https://linux-kernel-labs.github.io/refs/heads/master/labs/deferred_work.html#workqueues
> but the device still seems to hang at the blocking_notifier_call_chain()
> call. Is there something else I am missing here, other than leaving the irq
> context?

I do not know, I'm not going to dig around on random web sites for
patches, sorry :)

> > But step back, why would this driver ever want to shut down the machine
> > at all?  What problem are you trying to solve by making changes in this
> > driver?
> 
> This change is to help the factory team test the devices before they are
> fully assembled. There are a series of tests that they run on different
> components and being able to unplug the device to trigger a shutdown is one
> of their priorities. I hope that sheds some light on the context of these
> patches and the strange functionality I am trying to implement. Sorry if it
> caused any confusion.

Why are you trying to do this in the typec driver?  You should be able
to do all of this in userspace, just use libusb to get a list of devices
connected and when one is removed, reboot the machine.  There should not
be any need to write kernel code at all here.

Or, if you really want to write kernel code, do so for when you remove
the actual USB device itself, not in the typec code, so write a USB
driver for the USB device, not controller.

thanks,

greg k-h

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies