All of lore.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 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.