All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Allen Hubbe" <Allen.Hubbe@dell.com>
To: "'Serge Semin'" <fancer.lancer@gmail.com>, <jdmason@kudzu.us>,
	<dave.jiang@intel.com>, <Xiangliang.Yu@amd.com>
Cc: <Sergey.Semin@t-platforms.ru>, <linux-ntb@googlegroups.com>,
	<linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v3] NTB: Add IDT 89HPESxNTx PCIe-switches support
Date: Fri, 24 Feb 2017 11:01:00 -0500	[thread overview]
Message-ID: <000001d28eb7$3307bc30$99173490$@dell.com> (raw)
In-Reply-To: <1487933348-32403-1-git-send-email-fancer.lancer@gmail.com>

From: Serge Semin 
> IDT 89HPESxNTx device series is PCIe-switches, which support
...
> Signed-off-by: Serge Semin <fancer.lancer@gmail.com>

Acked-by: Allen Hubbe <Allen.Hubbe@dell.com>

With minor comments.  Please include my Ack if you send v4.


> +static u32 idt_nt_read(struct idt_ntb_dev *ndev, const unsigned int reg)
> +{
> +	/*
> +	 * It's obvious bug to request a register exceeding the maximum possible
> +	 * value as well as to have it unaligned.
> +	 */
> +	WARN_ON(reg > IDT_REG_PCI_MAX || !IS_ALIGNED(reg, IDT_REG_ALIGN));

if (WARN) return ~0?


> +/*
> + * idt_sw_write() - Global registers read method

Doc does not match fn:

> +static u32 idt_sw_read(struct idt_ntb_dev *ndev, const unsigned int reg)
> +{
> +	unsigned long irqflags;
> +	u32 data;
> +
> +	/*
> +	 * It's obvious bug to request a register exceeding the maximum possible
> +	 * value as well as to have it unaligned.
> +	 */
> +	WARN_ON(reg > IDT_REG_SW_MAX || !IS_ALIGNED(reg, IDT_REG_ALIGN));

if (WARN) return ~0?

> +
> +	/* Lock GASA registers operations */
> +	spin_lock_irqsave(&ndev->gasa_lock, irqflags);
> +	/* Set the global register address */
> +	writel((u32)reg, ndev->cfgspc + (ptrdiff_t)IDT_NT_GASAADDR);

I wonder how that HW will behave if we instruct it to do the general-purpose read out-of-bounds.  Better not.

> +	/* Get the data of the register */
> +	data = readl(ndev->cfgspc + (ptrdiff_t)IDT_NT_GASADATA);
> +	/* Unlock GASA registers operations */
> +	spin_unlock_irqrestore(&ndev->gasa_lock, irqflags);
> +
> +	return data;
> +}


> +static inline int idt_reg_clear_bits(struct idt_ntb_dev *ndev,
> +				     unsigned int reg, spinlock_t *reg_lock,
> +				     u64 valid_mask, u64 clear_bits)
> +{
> +	unsigned long irqflags;
> +	u32 data;
> +
> +	if (clear_bits & ~(u64)valid_mask)
> +		return -EINVAL;

This check also exists in the Intel driver (blame me).

I've wondered: what if we just pretend any non-valid bits are always "cleared."  If they are cleared again, just silently allow it (they stay cleared).  Only have this check against attempting to "set" invalid bits.

In Logan's ntb self-test with ntb_tool, it is convenient at the start of the test to "clear all the bits" of the doorbell registers.  This would be more simple if the script would just say "clear the bits ~0" instead of "tell me the valid bits and clear those."  Currently ntb_tool doesn't report the valid bits, so the valid bitset is a runtime parameter passed to the script (yuck).

Set the bits: are they valid?  ok.
Clear the bits: ok!


> +	/* It's useless to have this driver loaded if there is no any peer */
> +	if (ndev->peer_cnt == 0) {
> +		dev_err_pci(ndev, "No active peer found\n");
> +		return -EINVAL;
> +	}

Maybe it would be useful for development or debugging purposes?


> +static bool idt_ntb_local_link_is_up(struct idt_ntb_dev *ndev)
> +{
...
> +	if (!(data & IDT_NTMTBLDATA_VALID))
> +		return false;
> +
> +	/* Local NTB link is enabled if got here */
> +	return true;

Unnecessary branching logic.  Just:

return !!(data & IDT_NTMTBLDATA_VALID);

> +static bool idt_ntb_peer_link_is_up(struct idt_ntb_dev *ndev, int pidx)
> +{
...
> +	if (!(data & IDT_NTMTBLDATA_VALID))
> +		return false;
> +
> +	/* Peer NTB link is enabled if got here */
> +	return true;

return !!(data & IDT_NTMTBLDATA_VALID);

WARNING: multiple messages have this Message-ID (diff)
From: "Allen Hubbe" <Allen.Hubbe@dell.com>
To: 'Serge Semin' <fancer.lancer@gmail.com>,
	jdmason@kudzu.us, dave.jiang@intel.com, Xiangliang.Yu@amd.com
Cc: Sergey.Semin@t-platforms.ru, linux-ntb@googlegroups.com,
	linux-kernel@vger.kernel.org
Subject: RE: [PATCH v3] NTB: Add IDT 89HPESxNTx PCIe-switches support
Date: Fri, 24 Feb 2017 11:01:00 -0500	[thread overview]
Message-ID: <000001d28eb7$3307bc30$99173490$@dell.com> (raw)
In-Reply-To: <1487933348-32403-1-git-send-email-fancer.lancer@gmail.com>

From: Serge Semin 
> IDT 89HPESxNTx device series is PCIe-switches, which support
...
> Signed-off-by: Serge Semin <fancer.lancer@gmail.com>

Acked-by: Allen Hubbe <Allen.Hubbe@dell.com>

With minor comments.  Please include my Ack if you send v4.


> +static u32 idt_nt_read(struct idt_ntb_dev *ndev, const unsigned int reg)
> +{
> +	/*
> +	 * It's obvious bug to request a register exceeding the maximum possible
> +	 * value as well as to have it unaligned.
> +	 */
> +	WARN_ON(reg > IDT_REG_PCI_MAX || !IS_ALIGNED(reg, IDT_REG_ALIGN));

if (WARN) return ~0?


> +/*
> + * idt_sw_write() - Global registers read method

Doc does not match fn:

> +static u32 idt_sw_read(struct idt_ntb_dev *ndev, const unsigned int reg)
> +{
> +	unsigned long irqflags;
> +	u32 data;
> +
> +	/*
> +	 * It's obvious bug to request a register exceeding the maximum possible
> +	 * value as well as to have it unaligned.
> +	 */
> +	WARN_ON(reg > IDT_REG_SW_MAX || !IS_ALIGNED(reg, IDT_REG_ALIGN));

if (WARN) return ~0?

> +
> +	/* Lock GASA registers operations */
> +	spin_lock_irqsave(&ndev->gasa_lock, irqflags);
> +	/* Set the global register address */
> +	writel((u32)reg, ndev->cfgspc + (ptrdiff_t)IDT_NT_GASAADDR);

I wonder how that HW will behave if we instruct it to do the general-purpose read out-of-bounds.  Better not.

> +	/* Get the data of the register */
> +	data = readl(ndev->cfgspc + (ptrdiff_t)IDT_NT_GASADATA);
> +	/* Unlock GASA registers operations */
> +	spin_unlock_irqrestore(&ndev->gasa_lock, irqflags);
> +
> +	return data;
> +}


> +static inline int idt_reg_clear_bits(struct idt_ntb_dev *ndev,
> +				     unsigned int reg, spinlock_t *reg_lock,
> +				     u64 valid_mask, u64 clear_bits)
> +{
> +	unsigned long irqflags;
> +	u32 data;
> +
> +	if (clear_bits & ~(u64)valid_mask)
> +		return -EINVAL;

This check also exists in the Intel driver (blame me).

I've wondered: what if we just pretend any non-valid bits are always "cleared."  If they are cleared again, just silently allow it (they stay cleared).  Only have this check against attempting to "set" invalid bits.

In Logan's ntb self-test with ntb_tool, it is convenient at the start of the test to "clear all the bits" of the doorbell registers.  This would be more simple if the script would just say "clear the bits ~0" instead of "tell me the valid bits and clear those."  Currently ntb_tool doesn't report the valid bits, so the valid bitset is a runtime parameter passed to the script (yuck).

Set the bits: are they valid?  ok.
Clear the bits: ok!


> +	/* It's useless to have this driver loaded if there is no any peer */
> +	if (ndev->peer_cnt == 0) {
> +		dev_err_pci(ndev, "No active peer found\n");
> +		return -EINVAL;
> +	}

Maybe it would be useful for development or debugging purposes?


> +static bool idt_ntb_local_link_is_up(struct idt_ntb_dev *ndev)
> +{
...
> +	if (!(data & IDT_NTMTBLDATA_VALID))
> +		return false;
> +
> +	/* Local NTB link is enabled if got here */
> +	return true;

Unnecessary branching logic.  Just:

return !!(data & IDT_NTMTBLDATA_VALID);

> +static bool idt_ntb_peer_link_is_up(struct idt_ntb_dev *ndev, int pidx)
> +{
...
> +	if (!(data & IDT_NTMTBLDATA_VALID))
> +		return false;
> +
> +	/* Peer NTB link is enabled if got here */
> +	return true;

return !!(data & IDT_NTMTBLDATA_VALID);



  reply	other threads:[~2017-02-24 16:13 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-01 21:37 [PATCH] NTB: Add IDT 89HPESxNTx PCIe-switches support Serge Semin
2017-02-02 18:10 ` Allen Hubbe
2017-02-02 18:10   ` Allen Hubbe
2017-02-20 21:33 ` [PATCH v2] " Serge Semin
2017-02-21 22:42   ` Allen Hubbe
2017-02-21 22:42     ` Allen Hubbe
2017-02-22 11:01     ` Serge Semin
2017-02-24 10:49   ` [PATCH v3] " Serge Semin
2017-02-24 16:01     ` Allen Hubbe [this message]
2017-02-24 16:01       ` Allen Hubbe
2017-02-27  9:22     ` [PATCH v4] " Serge Semin
2017-03-01 16:30       ` Jon Mason
2017-03-03  6:38       ` lsgunthorpe
2017-03-07  1:57         ` Serge Semin
2017-03-07  3:27           ` Logan Gunthorpe
2017-03-07 15:09             ` Serge Semin
2017-03-07 17:00               ` Logan Gunthorpe
2017-03-07  2:02       ` [PATCH v5] " Serge Semin
2017-03-08 18:01         ` Jon Mason
2017-03-08 20:29         ` [PATCH v6] " Serge Semin
2017-04-12 12:44           ` [PATCH v7] " Serge Semin

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='000001d28eb7$3307bc30$99173490$@dell.com' \
    --to=allen.hubbe@dell.com \
    --cc=Sergey.Semin@t-platforms.ru \
    --cc=Xiangliang.Yu@amd.com \
    --cc=dave.jiang@intel.com \
    --cc=fancer.lancer@gmail.com \
    --cc=jdmason@kudzu.us \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-ntb@googlegroups.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.