public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Parker Newman <parker@finest.io>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jirislaby@kernel.org>,
	linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
	Parker Newman <pnewman@connecttech.com>
Subject: Re: [PATCH v3 7/8] serial: exar: add CTI specific setup code
Date: Wed, 17 Apr 2024 09:17:35 -0400	[thread overview]
Message-ID: <20240417091735.17686470@SWDEV2.connecttech.local> (raw)
In-Reply-To: <2024041726-fall-debunk-6cc5@gregkh>

On Wed, 17 Apr 2024 13:24:20 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> On Tue, Apr 16, 2024 at 08:55:34AM -0400, Parker Newman wrote:
> >  struct exar8250 {
> >  	unsigned int		nr;
> > +	unsigned int		osc_freq;
> > +	struct pci_dev		*pcidev;
> > +	struct device		*dev;
>
> Why do you need both a pci_dev and a device?  Aren't they the same thing
> here?
>

I added dev to make the prints cleaner. I personally prefer:

	dev_err(priv->dev, ...);
to
	dev_err(&priv->pcidev->dev, ...);

or to adding a:
	struct device *dev = &priv->pcidev->dev;

to every function just for printing.

However, I do understand your point. I can drop dev if you prefer.

> > +/**
> > + * _cti_set_tristate() - Enable/Disable RS485 transciever tristate
> > + * @priv: Device's private structure
> > + * @port_num: Port number to set tristate on/off
> > + * @enable: Enable tristate if true, disable if false
> > + *
> > + * Most RS485 capable cards have a power on tristate jumper/switch that ensures
> > + * the RS422/RS485 transciever does not drive a multi-drop RS485 bus when it is
> > + * not the master. When this jumper is installed the user must set the RS485
> > + * mode to disable tristate prior to using the port.
> > + *
> > + * Some Exar UARTs have an auto-tristate feature while others require setting
> > + * an MPIO to disable the tristate.
> > + *
> > + * Return: 0 on success, negative error code on failure
> > + */
> > +static int _cti_set_tristate(struct exar8250 *priv,
> > +			unsigned int port_num, bool enable)
> > +{
> > +	int ret = 0;
> > +
> > +	if (port_num >= priv->nr)
> > +		return -EINVAL;
> > +
> > +	// Only Exar based cards use MPIO, return 0 otherwise
> > +	if (priv->pcidev->vendor != PCI_VENDOR_ID_EXAR)
> > +		return 0;
>
> How can this ever happen?  Only the exar devices will call this
> function, or am I missing a path here?
>

Yes that can go now, it used to be needed but not now. I will remove.

>
> > +
> > +	dev_dbg(priv->dev, "%s tristate for port %u\n",
> > +		str_enable_disable(enable), port_num);
> > +
> > +	if (enable)
> > +		ret = exar_mpio_set_low(priv, port_num);
> > +	else
> > +		ret = exar_mpio_set_high(priv, port_num);
> > +	if (ret)
> > +		return ret;
> > +
> > +	// Ensure MPIO is an output
> > +	ret = exar_mpio_config_output(priv, port_num);
> > +
> > +	return ret;
> > +}
> > +
> > +static int cti_tristate_disable(struct exar8250 *priv, unsigned int port_num)
> > +{
> > +	return _cti_set_tristate(priv, port_num, false);
> > +}
>
> Do you ever call _cti_set_tristate() with "true"?
>

Currently no. However, re-enabling tristate via a custom ioctl was a feature in
our old out-of-tree driver (which was created prior to linux RS485 support).

I am not sure how it would be activated now, but I left enabling tristate as an
option in to make it easier down the line when we need it.

I can add a note to the patch or remove it if you would prefer.

> > +
> > +/**
> > + * _cti_set_plx_int_enable() - Enable/Disable PCI interrupts
> > + * @priv: Device's private structure
> > + * @enable: Enable interrupts if true, disable if false
>
> But false is never used here, so why have this at all?
>
> > + *
> > + * Some older CTI cards require MPIO_0 to be set low to enable the PCI
> > + * interupts from the UART to the PLX PCI->PCIe bridge.
> > + *
> > + * Return: 0 on success, negative error code on failure
> > + */
> > +static int _cti_set_plx_int_enable(struct exar8250 *priv, bool enable)
> > +{
> > +	int ret = 0;
> > +
> > +	// Only Exar based cards use MPIO, return 0 otherwise
> > +	if (priv->pcidev->vendor != PCI_VENDOR_ID_EXAR)
> > +		return 0;
>
> Same question here.
>

Same as above, not needed. I will remove.

> > +
> > +	if (enable)
> > +		ret = exar_mpio_set_low(priv, 0);
> > +	else
> > +		ret = exar_mpio_set_high(priv, 0);
> > +	if (ret)
> > +		return ret;
> > +
> > +	// Ensure MPIO is an output
> > +	ret = exar_mpio_config_output(priv, 0);
> > +
> > +	return ret;
> > +}
> > +
> > +static int cti_plx_int_enable(struct exar8250 *priv)
> > +{
> > +	return _cti_set_plx_int_enable(priv, true);
>
> Again, no wrapper needed if you never actually call that function with
> "false", right?  Or am I missing a path here?
>

This one is similar to _cti_set_tristate() but is less likely to be used.

Thanks again,
Parker

> thanks,
>
> greg k-h


  reply	other threads:[~2024-04-17 13:17 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-16 12:55 [PATCH v3 0/8] serial: exar: add Connect Tech serial cards to Exar driver Parker Newman
2024-04-16 12:55 ` [PATCH v3 1/8] serial: exar: adding missing CTI and Exar PCI ids Parker Newman
2024-04-17 11:17   ` Greg Kroah-Hartman
2024-04-16 12:55 ` [PATCH v3 2/8] serial: exar: remove old Connect Tech setup Parker Newman
2024-04-17 11:16   ` Greg Kroah-Hartman
2024-04-16 12:55 ` [PATCH v3 3/8] serial: exar: added a exar_get_nr_ports function Parker Newman
2024-04-17 11:15   ` Greg Kroah-Hartman
2024-04-17 12:21     ` Parker Newman
2024-04-16 12:55 ` [PATCH v3 4/8] serial: exar: add optional board_init function Parker Newman
2024-04-17 11:18   ` Greg Kroah-Hartman
2024-04-16 12:55 ` [PATCH v3 5/8] serial: exar: moved generic_rs485 further up in 8250_exar.c Parker Newman
2024-04-16 12:55 ` [PATCH v3 6/8] serial: exar: add CTI cards to exar_get_nr_ports Parker Newman
2024-04-16 12:55 ` [PATCH v3 7/8] serial: exar: add CTI specific setup code Parker Newman
2024-04-17 11:24   ` Greg Kroah-Hartman
2024-04-17 13:17     ` Parker Newman [this message]
2024-04-17 13:32       ` Greg Kroah-Hartman
2024-04-16 12:55 ` [PATCH v3 8/8] serial: exar: fix: fix crash during shutdown if setup fails Parker Newman
2024-04-17 11:19   ` Greg Kroah-Hartman
2024-04-17 12:24     ` Parker Newman
2024-04-17 13:30       ` Greg Kroah-Hartman
2024-04-17 16:32         ` Parker Newman
2024-04-17 11:24 ` [PATCH v3 0/8] serial: exar: add Connect Tech serial cards to Exar driver Greg Kroah-Hartman
2024-04-17 13:26   ` Parker Newman
2024-04-17 13:49     ` 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=20240417091735.17686470@SWDEV2.connecttech.local \
    --to=parker@finest.io \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=pnewman@connecttech.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox