linux-kernel - Re: [PATCH 2/9] add support for the TI VLYNQ bus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:  <loom.20090608T110141-763@post.gmane.org>
Date:	Mon, 8 Jun 2009 11:28:28 +0000 (UTC)
From:	Suraj Iyer <ssiyer@...com>
To:	linux-kernel@...r.kernel.org
Subject:  Re: [PATCH 2/9] add support for the TI VLYNQ bus

Florian Fainelli <florian <at> openwrt.org> writes:

> 
> This patch adds support for the TI VLYNQ high-speed,
> serial and packetized bus. This bus allows external
> devices to be connected to the System-on-Chip and
> appear in the main system memory just like any memory
> mapped peripheral. It is widely used in TI's networking
> and mutlimedia SoC, including the AR7 SoC.

In addition, the VLYNQ connectivity can also enable usage of one or more
simultaneous functionitilies (such as WLAN, Ethernet or other peripherals) of o
one SoC on another. In this sense, a single VLYNQ bus interface supports 
multifunctional devices or multiple peripherals and not just one peripheral or 
device.

> 
> ...
> ...
>
> +
> +int vlynq_set_local_mapping(struct vlynq_device *dev, u32 tx_offset,
> +			    struct vlynq_mapping *mapping)
> +{
> +	int i;
> +
> +	if (!dev->enabled)
> +		return -ENXIO;
> +
> +	vlynq_reg_write(dev->local->tx_offset, tx_offset);
> +	for (i = 0; i < 4; i++) {
> +		vlynq_reg_write(dev->local->rx_mapping[i].offset,
> +							mapping[i].offset);
> +		vlynq_reg_write(dev->local->rx_mapping[i].size,
> +							mapping[i].size);
> +	}
> +	return 0;
> +}
> +EXPORT_SYMBOL(vlynq_set_local_mapping);
> +
> +int vlynq_set_remote_mapping(struct vlynq_device *dev, u32 tx_offset,
> +			     struct vlynq_mapping *mapping)
> +{
> +	int i;
> +
> +	if (!dev->enabled)
> +		return -ENXIO;
> +
> +	vlynq_reg_write(dev->remote->tx_offset, tx_offset);
> +	for (i = 0; i < 4; i++) {
> +		vlynq_reg_write(dev->remote->rx_mapping[i].offset,
> +							mapping[i].offset);
> +		vlynq_reg_write(dev->remote->rx_mapping[i].size,
> +							mapping[i].size);
> +	}
> +	return 0;
> +}
> +EXPORT_SYMBOL(vlynq_set_remote_mapping);
> +

It seems that the current VLYNQ patch assumes that there is just one 
funcitonality or functional device (vlynq_device) that is attached with the 
VLYNQ. It will help to separate out the configuration of VLYNQ (through 
vlynq_set_local_mapping / vlynq_set_remote_mapping) from the functionalities 
(i.e. vlynq_device) that can be supported over VLYNQ. Once, the functional 
devices / drivers are isolated from the SoC specific VLYNQ configurations, the 
drivers can be independently re-used across multiple VLYNQ based SoC(s).   

Some of the other potential benefits, down the line, arising out of the 
stated isolation would be the discovery & auto-configuration of VLYNQ SoC(s), 
construction of daisy-chain and derive enumerated values (such as base 
addresses and interrupt numbers) required by the peripheral or functional
drivers.

Specifically, the VLYNQ (SoC) configuration is platform specific and 
functional drivers (vlynq_device & vlynq_driver) should not be attached to it.

Thanks,
Suraj

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/