All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Nuno Sá" <noname.nuno@gmail.com>
To: Wadim Mueller <wafgo01@gmail.com>
Cc: "Linmao Li" <lilinmao@kylinos.cn>,
	"Jonathan Cameron" <jic23@kernel.org>,
	"Maxwell Doose" <maxwell@maxwelld.cc>,
	"David Lechner" <dlechner@baylibre.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iio: flow: slf3s: restart measurement if VDD disable fails
Date: Thu, 6 Aug 2026 14:05:33 +0100	[thread overview]
Message-ID: <anSGfoKJGfXEL8VD@nsa> (raw)
In-Reply-To: <DKHVKU2TZOGF.3D3IRM9JEZS2Z@gmail.com>

On Thu, Aug 06, 2026 at 02:55:25PM +0200, Wadim Mueller wrote:
> On Thu Aug 6, 2026 at 11:39 AM CEST, Nuno Sá wrote:
> > On Wed, Aug 05, 2026 at 07:02:55PM +0800, Linmao Li wrote:
> >
> > I'm also not sure about the above. If the regulator fails to disable I
> > would say things are already in a bad state anyways. Is there any strong
> > reason to do `slf3s_send_cmd(sf->client, slf3s_cmd_stop_meas)` before
> > disabling vdd? I would assume that without vdd things will terminate
> > anyways. Asking because if we just disable it then the above stops
> > being a question. Though I do understand it's better to gracefully
> > terminate things. Just not sure if there's any added value for that in
> > this path.
> 
> on quite a few boards vdd is tied directly to the always-on rail, so there's
> no real supply node in the DT and the regulator core falls back to a dummy regulator there
> regulator_disable() becomes a pure no-op that always returns success without  actually removing power.
> so we can't rely on cutting vdd to stop the sensor

Oh yeah! That make total sense so dummy me :)

- Nuno Sá

> 
> Wadim
> 
> >
> > Just my 2 cents. No strong feelings so if the driver author is fine with
> > this, also looks like a sensible change.
> >
> > - Nuno Sá
> >
> > >  }
> > >  
> > >  static int slf3s_resume(struct device *dev)
> > > 
> > > base-commit: 0efaefce4e95a3331550329c0078b2fb38b3ff1f
> > > -- 
> > > 2.25.1
> > > 
> 

      reply	other threads:[~2026-08-06 13:04 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-05 11:02 [PATCH] iio: flow: slf3s: restart measurement if VDD disable fails Linmao Li
2026-08-05 12:59 ` David Lechner
2026-08-06  2:18   ` Linmao Li
2026-08-05 16:45 ` Maxwell Doose
2026-08-06  2:21   ` Linmao Li
2026-08-11  0:24     ` Maxwell Doose
2026-08-06  9:39 ` Nuno Sá
2026-08-06 12:55   ` Wadim Mueller
2026-08-06 13:05     ` Nuno Sá [this message]

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=anSGfoKJGfXEL8VD@nsa \
    --to=noname.nuno@gmail.com \
    --cc=andy@kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=jic23@kernel.org \
    --cc=lilinmao@kylinos.cn \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxwell@maxwelld.cc \
    --cc=nuno.sa@analog.com \
    --cc=wafgo01@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.