>> struct anybus_s_host *cd = data;
>> drivers/bus/anybus-s-host.c
>> include/linux/anybus-s-client.h
>
> Hm I think this looks pretty neat actually. Anyways, in the overall
> architecture explain the three Anybus:es and why things pertaining
> to Anybus-s are named as they are.
Ok, so should I
>> struct anybus_s_host *cd = data;
>> drivers/bus/anybus-s-host.c
>> include/linux/anybus-s-client.h
>
> Hm I think this looks pretty neat actually. Anyways, in the overall
> architecture explain the three Anybus:es and why things pertaining
> to Anybus-s are named as they are.
Ok, so should I
Hi Sven,
some tries to answer questions... (I am no expert in this but
I try my best)
On Thu, Oct 25, 2018 at 5:21 PM wrote:
> I had originally architected this driver to be much simpler, with everything
> running in the context of the userspace threads (except obviously the
> interrupt). But
Hi Sven,
some tries to answer questions... (I am no expert in this but
I try my best)
On Thu, Oct 25, 2018 at 5:21 PM wrote:
> I had originally architected this driver to be much simpler, with everything
> running in the context of the userspace threads (except obviously the
> interrupt). But
Hi Linus, thanks a million for the detailed patch review, you've given this
patch a lot more attention than I was expecting. Great !!
> What you need to add is a bit of how the driver is architected.
I agree. Written once, read/maintained 100s of times, right?
> This is really needed because
Hi Linus, thanks a million for the detailed patch review, you've given this
patch a lot more attention than I was expecting. Great !!
> What you need to add is a bit of how the driver is architected.
I agree. Written once, read/maintained 100s of times, right?
> This is really needed because
Hi Sven,
thanks for your patch!
On Wed, Oct 24, 2018 at 4:25 PM Sven Van Asbroeck wrote:
> This driver implementation is designed to be almost completely independent
> from the way the Anybus-S hardware is accessed by the SoC. All it needs is:
>
> - a regmap which accesses the underlying
Hi Sven,
thanks for your patch!
On Wed, Oct 24, 2018 at 4:25 PM Sven Van Asbroeck wrote:
> This driver implementation is designed to be almost completely independent
> from the way the Anybus-S hardware is accessed by the SoC. All it needs is:
>
> - a regmap which accesses the underlying
On 10/24/18 7:24 AM, Sven Van Asbroeck wrote:
> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
> index 1851112ccc29..68869648b9ab 100644
> --- a/drivers/bus/Kconfig
> +++ b/drivers/bus/Kconfig
> @@ -45,6 +45,17 @@ config IMX_WEIM
> The WEIM(Wireless External Interface Module) works
On 10/24/18 7:24 AM, Sven Van Asbroeck wrote:
> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
> index 1851112ccc29..68869648b9ab 100644
> --- a/drivers/bus/Kconfig
> +++ b/drivers/bus/Kconfig
> @@ -45,6 +45,17 @@ config IMX_WEIM
> The WEIM(Wireless External Interface Module) works
The Anybus-S/Anybus-M is a series of interchangeable fieldbus communication
modules featuring on board memory and processing power. All software and
hardware functionality required to communicate on the fieldbus is
incorporated in the module itself, allowing the application to focus on
other
The Anybus-S/Anybus-M is a series of interchangeable fieldbus communication
modules featuring on board memory and processing power. All software and
hardware functionality required to communicate on the fieldbus is
incorporated in the module itself, allowing the application to focus on
other
12 matches
Mail list logo
