From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: "Martin Zaťovič" <m.zatovic1@gmail.com>
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
mani@kernel.org, hemantk@codeaurora.org, quic_jhugo@quicinc.com,
andersson@kernel.org, Michael.Srba@seznam.cz, arnd@arndb.de,
dipenp@nvidia.com, bvanassche@acm.org, iwona.winiarska@intel.com,
ogabbay@kernel.org, tzimmermann@suse.de, fmdefrancesco@gmail.com,
jason.m.bills@linux.intel.com, jae.hyun.yoo@linux.intel.com,
gregkh@linuxfoundation.org, krzysztof.kozlowski+dt@linaro.org,
robh+dt@kernel.org
Subject: Re: [PATCH 3/3] wiegand: add Wiegand GPIO bit-banged controller driver
Date: Wed, 4 Jan 2023 18:59:00 +0200 [thread overview]
Message-ID: <Y7WwVCqDCXFrTqR9@smile.fi.intel.com> (raw)
In-Reply-To: <20230104133414.39305-4-m.zatovic1@gmail.com>
On Wed, Jan 04, 2023 at 02:34:14PM +0100, Martin Zaťovič wrote:
> This controller formats the data to a Wiegand format - appends
> checksum if one of the defined formats is used - and bit-bangs
> the message on devicetree defined GPIO lines.
>
> Several attributes need to be defined in the devicetree in order
> for this driver to work, namely the data-hi-gpios, data-lo-gpios,
> pulse-len, frame-gap and interval-len. These attributes are
> documented in the devicetree binding documentation file.
>
> The driver creates a dev file for writing messages on the bus.
> It also creates two sysfs files to control the format and payload
> length of messages. Defined formats are 26, 36 and 37-bit, meaning
> the payloads for these formats are 24, 34 and 35 bit respectively,
> as two bits are allocated for checksum. A custom format is also
> supported and it is set by writing 0 to the format sysfs file.
> Custom format does not calculate and append checksum to messages -
> they are bit-banged as inputted.
Brief look at the code makes me think that this is something from 10 years ago
with slightly removed dust to make it compile. So far I have noticed:
- explicit castings where it's not needed
- bad indentation here and there
- using direct dereference in the cases when we have specific getters available
- NIH this and that
...
> +What: /sys/devices/platform/.../wiegand-gpio-attributes/format
> +Date: January 2023
> +Contact: Martin Zaťovič <m.zatovic1@gmail.com>
> +Description:
> + Read/set Wiegand communication format.
> + 0 - custom format, payload length is specified by
> + payload_len file
> + 26 - 26-bit format (24 bit payload, 2 bits checksum)
> + 36 - 36-bit format (34 bit payload, 2 bits checksum)
> + 37 - 37-bit format (35 bit payload, 2 bits checksum)
> +
> +What: /sys/devices/platform/.../wiegand-gpio-attributes/payload_len
> +Date: January 2023
> +Contact: Martin Zaťovič <m.zatovic1@gmail.com>
> +Description:
> + Read/set Wiegand communication payload length. File is only
> + writable if custom format is set.
Why all these attributes? What is special about them and how they are specific
to the hardware in question?
To me it all sounds like layering violation: a GPIO driver that has to be
generic provides a complete custom ABIs which we usually put on the upper
layer (in the kernel as a child driver or in the user space).
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2023-01-04 17:04 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-04 13:34 [PATCH 0/3] Wiegand bus driver and GPIO controller driver Martin Zaťovič
2023-01-04 13:34 ` [PATCH 1/3] dt-bindings: add Wiegand controller dt-binding documentation Martin Zaťovič
2023-01-05 2:53 ` Rob Herring
2023-01-05 2:53 ` Rob Herring
2023-01-08 16:30 ` Rob Herring
2023-01-22 14:21 ` Krzysztof Kozlowski
2023-01-04 13:34 ` [PATCH 2/3] bus: add Wiegand bus driver Martin Zaťovič
2023-01-04 14:03 ` Greg KH
2023-01-04 14:05 ` Greg KH
2023-01-25 13:05 ` Martin Zaťovič
2023-01-25 13:16 ` Arnd Bergmann
2023-01-25 13:21 ` Martin Zaťovič
2023-01-25 13:26 ` Greg KH
2023-01-25 13:37 ` Martin Zaťovič
2023-01-04 14:06 ` Greg KH
2023-01-04 13:34 ` [PATCH 3/3] wiegand: add Wiegand GPIO bit-banged controller driver Martin Zaťovič
2023-01-04 14:05 ` Greg KH
2023-01-04 16:39 ` kernel test robot
2023-01-04 16:59 ` Andy Shevchenko [this message]
2023-01-04 17:01 ` Andy Shevchenko
2023-01-25 9:28 ` Martin Zaťovič
2023-01-25 11:49 ` Andy Shevchenko
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=Y7WwVCqDCXFrTqR9@smile.fi.intel.com \
--to=andriy.shevchenko@intel.com \
--cc=Michael.Srba@seznam.cz \
--cc=andersson@kernel.org \
--cc=arnd@arndb.de \
--cc=bvanassche@acm.org \
--cc=devicetree@vger.kernel.org \
--cc=dipenp@nvidia.com \
--cc=fmdefrancesco@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=hemantk@codeaurora.org \
--cc=iwona.winiarska@intel.com \
--cc=jae.hyun.yoo@linux.intel.com \
--cc=jason.m.bills@linux.intel.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.zatovic1@gmail.com \
--cc=mani@kernel.org \
--cc=ogabbay@kernel.org \
--cc=quic_jhugo@quicinc.com \
--cc=robh+dt@kernel.org \
--cc=tzimmermann@suse.de \
/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;
as well as URLs for NNTP newsgroup(s).