RE: [PATCH v5 0/9] Add RZ/G2L POEG support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Linus Walleij,

Thanks for the feedback.

> Subject: Re: [PATCH v5 0/9] Add RZ/G2L POEG support
> 
> On Mon, Jan 9, 2023 at 4:10 PM Biju Das <biju.das.jz@xxxxxxxxxxxxxx> wrote:
> 
> > > What's wrong with using the debugfs approach Drew implemented in
> > > commit 6199f6becc869d30ca9394ca0f7a484bf9d598eb
> > > "pinctrl: pinmux: Add pinmux-select debugfs file"
> > > ?
> >
> > I am not sure, we supposed to use debugfs for production environment??
> 
> It depends what is meant by "production environment".

Sorry for the confusion. I meant the final product used by the customers.

I was under the impression that debugfs is for hacks and debugging.
(For eg: if the HW doesn't have a USB3 function port, but using debugfs,
we can emulate the condition and test)

> 
> If you mean a controlled environment "one-off" such as a factory line, a
> specific installation for a specific purpose such as a water purifier, that
> is very custom and hacked together for that one usecase. It will have other
> hacks too, so then Beagle is using debugfs in "production"
> if that is what you mean by "production", i.e. used to produce something.
> 
> This is the same "production" use cases as used by i.e. the GPIO character
> device.
> 
> If you mean that you are producing 6 million laptops where userspace is
> going to hammer this constantly, then no. In that case a real sysfs knob and
> ABI contract is needed.
> 
> Usually vendors know which usecase their hardware is intended for, there is
> in my experience no unknown target audience, so which one is it in your
> case?

POEG use case is related to protection from system failure(disable output pins in case of short circuits)

Either

1) we detect externally and use software control to disable output pins --> Here I am using sysfs variable
(/sys/devices/platform/soc/10049400.poeg/output_disable) to control it.

Or

2) we detect externally and send an active level signal to disable output pins

Or

3) we detect internally using GPT(PWM) and disable output pins --> Here 3 options or combination is possible
                              for configuring the short circuit detection like
		1) Dead Time Error Output Disable Request Enable
		2) Same Time Output Level High Disable Request Enable
		3) Same Time Output Level Low Disable Request Enable

I have exported 3 sysfs variables for configuring these 3 options.
  1) /sys/devices/platform/soc/10049400.poeg/gpt_req_both_high
  2) /sys/devices/platform/soc/10049400.poeg/gpt_req_both_low
  3) /sys/devices/platform/soc/10049400.poeg/gpt_req_deadtime_err

> 
> > > such as a list of stuff to be exported as sysfs switches.
> >
> > Can you please elaborate? Or Point me to an example for this?
> 
> Not sure what to say about that, you will have to invent something I'm
> afraid, good examples are in Documentation/ABI.

If it is preferable to use debugfs compared to sysfs for the use cases I mentioned above,
I could change it to debugfs like Drew's patch. Please let me know.

Cheers,
Biju




[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux