[1/4] dt-bindings: Add vendor prefix for Silvaco

Silvaco, Inc. is an EDA provider of software tools used for process
and device development and for analog/mixed-signal, power IC and
memory design [1].

[1] https://www.silvaco.com/company/profile/profile.html

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

On Thu, Jul 09, 2020 at 10:01:56AM +0200, Miquel Raynal wrote:
> Silvaco, Inc. is an EDA provider of software tools used for process
> and device development and for analog/mixed-signal, power IC and
> memory design [1].
> 
> [1] https://www.silvaco.com/company/profile/profile.html
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 9aeab66be85f..5933966db783 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -1004,6 +1004,8 @@ patternProperties:
>      description: Shenzhen Sunchip Technology Co., Ltd
>    "^SUNW,.*":
>      description: Sun Microsystems, Inc
> +  "^svc,.*":

Why not 'silvaco'?

> +    description: Silvaco, Inc.
>    "^swir,.*":
>      description: Sierra Wireless
>    "^syna,.*":
> -- 
> 2.20.1
>

On Thu, 9 Jul 2020, Miquel Raynal wrote:

> Add support for Silvaco I3C dual-role IP. The master role is supported
> in SDR mode only. I2C transfers have not been tested but are shared
> because they are so close to the I3C transfers in terms of registers
> configuration.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

I'm worried by constructs like these:

> +static int svc_i3c_master_handle_ibi(struct svc_i3c_master *master,
> +				     struct i3c_dev_desc *dev)
> +{
> +	struct svc_i3c_i2c_dev_data *data = i3c_dev_get_master_data(dev);
> +	struct i3c_ibi_slot *slot;
> +	unsigned int count;
> +	u32 mdatactrl;
> +	u8 *buf;
> +	int ret;
> +	u32 reg;
> +
> +	spin_lock(&master->ibi.lock);
> +
> +	slot = i3c_generic_ibi_get_free_slot(data->ibi_pool);
> +	if (!slot) {
> +		ret = -ENOSPC;
> +		goto unlock;
> +	}
> +
> +	slot->len = 0;
> +	buf = slot->data;
> +
> +	ret = readl_poll_timeout(master->regs + SVC_I3C_MSTATUS, reg,
> +				 reg & SVC_I3C_MINT_RXPEND, 0, 1000);

Here you're in atomic context due to the lock, and 
readl_poll_timeout(() is built using usleep() which may ... sleep.

Also, is it actually possible for execution to reach this point if 
SVC_I3C_MINT_RXPEND is not set?

The rest looks reasonable to me.


Nicolas

On Tue, 4 Aug 2020, Conor Culhane wrote:

> Miquel is passing 0 as the delay_us argument.

Good point.

> Is this still a concern?

Not in that case.


Nicolas

Hi Nicolas,

Nicolas Pitre <nico@fluxnic.net> wrote on Wed, 5 Aug 2020 11:13:41
-0400 (EDT):

> On Tue, 4 Aug 2020, Conor Culhane wrote:
> 
> > Miquel is passing 0 as the delay_us argument.  
> 
> Good point.
> 
> > Is this still a concern?  
> 
> Not in that case.

I will check again if looping over this register read actually
makes sense or not. If yes, I will add a comment here.

Thanks,
Miquèl