devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "József Horváth" <info@ministro.hu>
To: "Jérôme Pouiller" <jerome.pouiller@silabs.com>
Cc: 'Rob Herring' <robh+dt@kernel.org>,
	'Greg Kroah-Hartman' <gregkh@linuxfoundation.org>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	devel@driverdev.osuosl.org,
	driverdev-devel@linuxdriverproject.org
Subject: Re: [PATCH] Staging: silabs si4455 serial driver
Date: Wed, 9 Dec 2020 19:41:53 +0000	[thread overview]
Message-ID: <20201209194153.GC30918@dincontrollerdev> (raw)
In-Reply-To: <2907305.Mh6RI2rZIc@pc-42>

Hello Jérôme,

On Wed, Dec 09, 2020 at 06:38:08PM +0100, Jérôme Pouiller wrote:
> On Wednesday 9 December 2020 12:09:58 CET Info wrote:
> > 
> > This is a serial port driver for
> > Silicon Labs Si4455 Sub-GHz transciver.
> 
> Hello József,
> 
> Thank you for taking care of support of Silabs products :)

I think great products :) and great support :)

> 
> 
> > Signed-off-by: József Horváth <info@ministro.hu>
> 
> I think you have to use your personal address to sign-off.

I'm a self-employed, currently this is my "personal" e-mail address.

> 
> > ---
> >  .../bindings/staging/serial/silabs,si4455.txt |   39 +
> >  drivers/staging/Kconfig                       |    2 +
> >  drivers/staging/Makefile                      |    1 +
> >  drivers/staging/si4455/Kconfig                |    8 +
> >  drivers/staging/si4455/Makefile               |    2 +
> >  drivers/staging/si4455/TODO                   |    3 +
> >  drivers/staging/si4455/si4455.c               | 1465 +++++++++++++++++
> >  drivers/staging/si4455/si4455_api.h           |   56 +
> >  8 files changed, 1576 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/staging/serial/silabs,si4455.txt
> >  create mode 100644 drivers/staging/si4455/Kconfig
> >  create mode 100644 drivers/staging/si4455/Makefile
> >  create mode 100644 drivers/staging/si4455/TODO
> >  create mode 100644 drivers/staging/si4455/si4455.c
> >  create mode 100644 drivers/staging/si4455/si4455_api.h
> 
> Since you add a new directory, you should also update MAINTAINERS file
> (checkpatch didn't warn you about that?).
> 
> 
> > diff --git
> > a/Documentation/devicetree/bindings/staging/serial/silabs,si4455.txt
> > b/Documentation/devicetree/bindings/staging/serial/silabs,si4455.txt
> > new file mode 100644
> > index 000000000000..abd659b7b952
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/staging/serial/silabs,si4455.txt
> > @@ -0,0 +1,39 @@
> > +* Silicon Labs Si4455 EASY-TO-USE, LOW-CURRENT OOK/(G)FSK SUB-GHZ
> > TRANSCEIVER
> 
> AFAIK, Si4455 is a programmable product. So I think that this driver only
> work if the Si4455 use a specific firmware, isn't? In this case, you
> should mention it in the documentation. 

Si4455 is programmed by silabs.
In case of C2A, it is possible to load patch.

My solution is to loading EZConfig(generated by WDS) and firmware patch with ioctl calls.
You can see the definitions in si4455_api.h.
A short example for EZConfig loading(patch loading will be exacly the same if Si4455 is rev C2A):
	...
	#include "si4455_api.h"
	...
	#include "radio.h"			//< Generated by WDS3
	#include "radio_config_Si4455.h"	//< Generated by WDS3
	...
	struct si4455_iocbuff iocbuff = { 0 };
	iocbuff.length = sizeof(Radio_Configuration_Data_Array);
	memcpy(iocbuff.data, Radio_Configuration_Data_Array, iocbuff.length);
	ret = ioctl(portFd, SI4455_IOC_SEZC, &iocbuff);
	...

After SI4455_IOC_SEZC or SI4455_IOC_SEZP ioctl calls, the driver resets the Si4455, and apply the configuration/patch.

> 
> 
> > +
> > +Required properties:
> > +- compatible: Should be one of the following:
> > +  - "silabs,si4455" for Silicon Labs Si4455-B1A or Si4455-C2A (driver
> > automatically detects the part info),
> > +  - "silabs,si4455b1a" for Silicon Labs Si4455-B1A,
> > +  - "silabs,si4455c2a" for Silicon Labs Si4455-C2A,
> > +- reg: SPI chip select number.
> > +- interrupts: Specifies the interrupt source of the parent interrupt
> > +  controller. The format of the interrupt specifier depends on the
> > +  parent interrupt controller.
> > +- clocks: phandle to the IC source clock (only external clock source
> > supported).
> > +- spi-max-frequency: maximum clock frequency on SPI port
> > +- shdn-gpios: gpio pin for SDN
> > +
> > +Example:
> > +
> > +/ {
> > +       clocks {
> > +                si4455_1_2_osc: si4455_1_2_osc {
> > +                        compatible = "fixed-clock";
> > +                        #clock-cells = <0>;
> > +                        clock-frequency  = <30000000>;
> > +                };
> > +       };
> > +};
> > +
> > +&spi0 {
> > +       si4455: si4455@0 {
> > +               compatible = "silabs,si4455";
> > +               reg = <0>;
> > +               clocks = <&si4455_1_2_osc>;
> 
> It seems that the driver does not use this clock. So, is the clock
> attribute mandatory? What is the purpose of declaring a fixed-clock
> for this device?
> 

Yes you are right, but the uart subsystem maybe. I'll check it again, and if does not, I'll remove these definitions.

> > +               interrupt-parent = <&gpio>;
> > +               interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
> > +                shdn-gpios = <&gpio 26 1>;
> > +                status = "okay";
> > +                spi-max-frequency = <3000000>;
> > +       };
> > +};
> 
> [...]
> 
> 
> > diff --git a/drivers/staging/si4455/Kconfig b/drivers/staging/si4455/Kconfig
> > new file mode 100644
> > index 000000000000..666f726f2583
> > --- /dev/null
> > +++ b/drivers/staging/si4455/Kconfig
> > @@ -0,0 +1,8 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +config SERIAL_SI4455
> > +       tristate "Si4455 support"
> > +       depends on SPI
> > +       select SERIAL_CORE
> > +       help
> > +         This driver is for Silicon Labs's Si4455 Sub-GHz transciver.
> > +         Say 'Y' here if you wish to use it as serial port.
> 
> So, in fact, Si4455 is not a UART. I don't know how this kind of device
> should be presented to the userspace. Have you check if similar devices
> already exists in the kernel?

I know Si4455 is not a regular UART, but in my mind it is a half-duplex serial transport channel, like UART with RS-485.
This is the reason why I designed it among serial drivers.
The special funcions like tx/rx channel, package size are controlled with ioctl calls.

> 
> I suggest to add linux-wpan@vger.kernel.org to the recipients of your
> patch.
> 
> 
> [...]
> > +static int si4455_get_part_info(struct uart_port *port,
> > +                               struct si4455_part_info *result)
> > +{
> > +       int ret;
> > +       u8 dataOut[] = { SI4455_CMD_ID_PART_INFO };
> > +       u8 dataIn[SI4455_CMD_REPLY_COUNT_PART_INFO];
> > +
> > +       ret = si4455_send_command_get_response(port,
> > +                                               sizeof(dataOut),
> > +                                               dataOut,
> > +                                               sizeof(dataIn),
> > +                                               dataIn);
> 
> Why not:
> 

I changed all like this in my code already. I test it, and I'll send it again.

Ps.: For my eyes is better to read line or list, reading table is harder :)

	line(arg1, arg2, arg3, arg4);

	list(arg1,
		arg2,
		arg3,
		arg4);

	table(arg1, arg2,
		arg3, arg4);


>        ret = si4455_send_command_get_response(port,
>                                               sizeof(*result), result,
>                                               sizeof(dataIn), dataIn);
> 
> > +       if (ret == 0) {
> > +               result->CHIPREV = dataIn[0];
> > +               memcpy(&result->PART, &dataIn[1],sizeof(result->PART));
> > +               result->PBUILD = dataIn[3];
> > +               memcpy(&result->ID, &dataIn[4], sizeof(result->ID));
> > +               result->CUSTOMER = dataIn[6];
> > +               result->ROMID = dataIn[7];
> > +               result->BOND = dataIn[8];
> 
> ... it would avoid all these lines.
> 
> > +       } else {
> > +               dev_err(port->dev,
> > +                       "%s: si4455_send_command_get_response error(%i)",
> > +                       __func__,
> > +                       ret);
> > +       }
> > +       return ret;
> > +}
> 
> [...]
> 
> -- 
> Jérôme Pouiller
> 
> 

Üdvözlettel / Best regards:
József Horváth


  reply	other threads:[~2020-12-09 19:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-09 11:09 [PATCH] Staging: silabs si4455 serial driver Info
2020-12-09 12:02 ` 'Greg Kroah-Hartman'
2020-12-09 12:57   ` ***UNCHECKED*** " Info
2020-12-09 12:42 ` Dan Carpenter
2020-12-09 18:56   ` József Horváth
2020-12-09 18:59     ` Dan Carpenter
2020-12-09 17:38 ` Jérôme Pouiller
2020-12-09 19:41   ` József Horváth [this message]
2020-12-10  8:00     ` Dan Carpenter
2020-12-10  3:06 ` Rob Herring
  -- strict thread matches above, loose matches on Subject: below --
2020-12-10 12:20 József Horváth
2020-12-10 12:55 ` 'Greg Kroah-Hartman'

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=20201209194153.GC30918@dincontrollerdev \
    --to=info@ministro.hu \
    --cc=devel@driverdev.osuosl.org \
    --cc=devicetree@vger.kernel.org \
    --cc=driverdev-devel@linuxdriverproject.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jerome.pouiller@silabs.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    /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).