From: Lee Jones <lee.jones@linaro.org>
To: Kishon Vijay Abraham I <kishon@ti.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kernel@stlinux.com,
Alexandre Torgue <alexandre.torgue@st.com>
Subject: Re: [PATCH 3/5] phy: miphy365x: Provide support for the MiPHY356x Generic PHY
Date: Thu, 3 Jul 2014 09:07:58 +0100 [thread overview]
Message-ID: <20140703080758.GI30534@lee--X1> (raw)
In-Reply-To: <53B3DCBC.8000105@ti.com>
On Wed, 02 Jul 2014, Kishon Vijay Abraham I wrote:
> On Monday 30 June 2014 06:31 PM, Lee Jones wrote:
> > The MiPHY365x is a Generic PHY which can serve various SATA or PCIe
> > devices. It has 2 ports which it can use for either; both SATA, both
> > PCIe or one of each in any configuration.
> >
> > Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Removed.
> > Acked-by: Mark Rutland <mark.rutland@arm.com>
> > Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > drivers/phy/Kconfig | 10 +
> > drivers/phy/Makefile | 1 +
> > drivers/phy/phy-miphy365x.c | 630 ++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 641 insertions(+)
> > create mode 100644 drivers/phy/phy-miphy365x.c
[...]
> > +struct miphy365x_dev {
> > + struct device *dev;
> > + struct mutex miphy_mutex;
> > + struct miphy365x phys[ARRAY_SIZE(ports)];
>
> Avoid using fixed array sizes for ports or channels. Refer [1].
Just addressing this point in this mail. Any other subsequent points
will either be fixed up or addressed in other correspondence.
I don't agree with this point. I don't believe the number of channels
should be dictated by the number of DT sub-nodes supplied. Instead,
the driver should contain knowledge about what is supported and
validate the DT data accordingly. If it's omitted we lose the ability
to conduct any kind of bounds checking, such like the following:
if (WARN_ON(port >= ARRAY_SIZE(ports)))
return ERR_PTR(-EINVAL);
And
if (child_count != ARRAY_SIZE(ports)) {
dev_err(&pdev->dev, "%d ports supported, %d supplied\n",
ARRAY_SIZE(ports), child_count);
return -EINVAL;
}
If at a later point, we need to expand the driver to support a new
chip which supports more channels/ports then we need to expand the
bounds checking based on match data extracted from the supplied
compatible string. For instance, if a 4 port controller is being used
and only 2 channels have been supplied, or vice versa then probe()
should fail.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2014-07-03 8:08 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-30 13:01 [PATCH 0/5] phy: miphy365x: Introduce support for MiPHY365x Lee Jones
2014-06-30 13:01 ` [PATCH 1/5] phy: miphy365x: Add Device Tree bindings for the MiPHY365x Lee Jones
2014-07-02 9:24 ` Kishon Vijay Abraham I
2014-07-02 12:06 ` Lee Jones
2014-07-03 9:06 ` Kishon Vijay Abraham I
2014-06-30 13:01 ` [PATCH 2/5] phy: miphy365x: Add MiPHY365x header file for DT x Driver defines Lee Jones
2014-07-02 9:28 ` Kishon Vijay Abraham I
2014-07-02 12:02 ` Lee Jones
2014-06-30 13:01 ` [PATCH 3/5] phy: miphy365x: Provide support for the MiPHY356x Generic PHY Lee Jones
2014-07-02 10:19 ` Kishon Vijay Abraham I
2014-07-02 12:00 ` Lee Jones
2014-07-03 8:07 ` Lee Jones [this message]
2014-07-03 10:06 ` Kishon Vijay Abraham I
2014-07-04 13:55 ` Gabriel Fernandez
2014-07-08 7:15 ` Lee Jones
2014-06-30 13:01 ` [PATCH 4/5] phy: miphy365x: Represent each PHY channel as a subnode Lee Jones
2014-06-30 13:06 ` [STLinux Kernel] " Maxime Coquelin
2014-06-30 13:52 ` Lee Jones
2014-06-30 14:41 ` [PATCH v2 " Lee Jones
2014-07-02 10:26 ` Kishon Vijay Abraham I
2014-07-02 11:34 ` Lee Jones
2014-07-02 11:57 ` Kishon Vijay Abraham I
2014-07-02 12:19 ` Lee Jones
2014-06-30 13:01 ` [PATCH 5/5] ARM: DT: STi: Add DT node for MiPHY365x Lee Jones
2014-07-03 14:08 ` Gabriel Fernandez
2014-07-02 9:19 ` [PATCH 0/5] phy: miphy365x: Introduce support " Kishon Vijay Abraham I
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=20140703080758.GI30534@lee--X1 \
--to=lee.jones@linaro.org \
--cc=alexandre.torgue@st.com \
--cc=kernel@stlinux.com \
--cc=kishon@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.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