Re: Remote IP setup of devices in a network
On Tue, 2011-11-08 at 20:31 +0100, Sam Ravnborg wrote: > On Tue, Nov 08, 2011 at 07:11:09PM +, David Woodhouse wrote: > > On Tue, 2011-11-08 at 19:54 +0100, Sam Ravnborg wrote: > > > The idea is to use an UDP broadcast to discover all devices, > > > and a similar UDP broadcast to configure the devices. > > > In the latter the MAC will be the key to address individual devices. > > > > You could almost be describing link-local IPv6. Each device > > automatically gets an IPv6 address based on its MAC address, which you > > can use for unicast addressing. The broadcast (or multicast) bit is easy > > enough too. > > We are forced to use a IPv4 network where we need to keep the devices > in the same network as a potential router. Note that to use *link-local* IPv6 you don't need any co-operation from infrastructure. You don't need global routing; you don't need to be generally operating in 21st century conditions. If you have an Ethernet-like link between your devices, link-local IPv6 should work fine. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: Remote IP setup of devices in a network
On 09/11/11 08:31, Sam Ravnborg wrote: > On Tue, Nov 08, 2011 at 07:11:09PM +, David Woodhouse wrote: >> On Tue, 2011-11-08 at 19:54 +0100, Sam Ravnborg wrote: >>> The idea is to use an UDP broadcast to discover all devices, >>> and a similar UDP broadcast to configure the devices. >>> In the latter the MAC will be the key to address individual devices. It isn't obvious why you can't use bootp or dhcp? -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Remote IP setup of devices in a network
On Tue, Nov 08, 2011 at 07:11:09PM +, David Woodhouse wrote: > On Tue, 2011-11-08 at 19:54 +0100, Sam Ravnborg wrote: > > The idea is to use an UDP broadcast to discover all devices, > > and a similar UDP broadcast to configure the devices. > > In the latter the MAC will be the key to address individual devices. > > You could almost be describing link-local IPv6. Each device > automatically gets an IPv6 address based on its MAC address, which you > can use for unicast addressing. The broadcast (or multicast) bit is easy > enough too. We are forced to use a IPv4 network where we need to keep the devices in the same network as a potential router. So to describe the idea with a little drawing: Host PCDevice-1 Device-2 | || | DISCOVER->|--->| | || |<-- REPLY(MAC:IP)--|| |<-- REPLY(MAC:IP)---| | || (technician manually decide IP setup) | || |-- CONFIG(MAC:IP)->|| |-- CONFIG(MAC:IP)-->| The discover is maybe sent twice due to packer drops. The Reply is sent once and may look like this: MAC=01:02:03:04:05:06;IP=10.11.12.13;NM=255.0.0.0;GW=10.0.0.1;XX="foo bar";YY="baz buz" The technician then decides the new config (or computer assisted). And the CONFIG may look like this: MAC=01:02:03:04:05:06;IP=192.168.0.201;NM=255.255.255.0;GW=192.168.0.1 I cannot get this with auto-IP or wahtever it is named for IPv4. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Remote IP setup of devices in a network
On Tue, 2011-11-08 at 19:54 +0100, Sam Ravnborg wrote: > The idea is to use an UDP broadcast to discover all devices, > and a similar UDP broadcast to configure the devices. > In the latter the MAC will be the key to address individual devices. You could almost be describing link-local IPv6. Each device automatically gets an IPv6 address based on its MAC address, which you can use for unicast addressing. The broadcast (or multicast) bit is easy enough too. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Remote IP setup of devices in a network
I am faced with a challenge that we ship devices which are all preconfigured to a fixed IP address, and we want to provide an easy solution to do remote IP configuration of all devices connected to the same network. In other words - all devices are reachable by a broadcast package. The network may or may not include a DHCP server - which we in any case do not have control over. In the typical situation we will assign static IP addresses to the devices - but sometimes we may also configure them to DHCP. So we are looking for a (de facto?) way to do this. Any hints? I haved tried to ask google without luck. The idea is to use an UDP broadcast to discover all devices, and a similar UDP broadcast to configure the devices. In the latter the MAC will be the key to address individual devices. As we are talking less than 100 devices this looks quite doable. But I do not want to invent something again if it already exists. Thanks in advance for any inputs, Sam -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A new Subsystem for Current Management
On Tue, Nov 08, 2011 at 04:39:17PM +0530, R, Durgadoss wrote: > [I have posted this on lm-sensors and platform-drivers-x86 > lists earlier. As per some recommendations there, posting it > here] lkml would probably be useful. It'd also help if you could publish code along with your mail, in general people are much more likely to review concrete code. > In simple terms, this framework will offer something like this: > Current[1-N]_limit - set of current limits > Voltage[1-X]_limit - set of voltage limits What would the voltage limits be? Whatever is going on here there should be some integration with the regulator framework, modern regulators are often able to report when they go out of regulator and able to impose current limits. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A new Subsystem for Current Management
On 08/11/11 11:09, R, Durgadoss wrote:
Hi All,
Hi Durga,
[Very Sorry for the Big Email]
[I have posted this on lm-sensors and platform-drivers-x86
lists earlier. As per some recommendations there, posting it
here]
As we all know, Linux is increasingly being used in handhelds.
The Hardware that supports the handhelds is also becoming
Performance-centric. With this, we need a way to efficiently
monitor the current consumption of the platform and take actions
when the platform draws more current, than it should.
Where this can happen ?
---
In a handheld, there are many components that demand high
Current. For example, Camera Flash, Video Streaming, 3G Voice
Call etc. Typically, two or more of these components are used
simultaneously in a real-time scenario. When this happens, the
current draw of the platform surges. If this surge lasts for
more than a specific time, it could crash the platform irrecoverably.
How do we tackle this ?
---
In Intel Medfield (Atom based) platform we had a driver that
Configures the current limits. When the platform current draws
more current than the programmed limit, the hardware generates
interrupt. The driver receives this interrupt and notifies the
user space to take appropriate actions.
The patch and the subsequent discussions can be found here:
http://comments.gmane.org/gmane.linux.drivers.platform.x86.devel/1197
To Generalize:
--
With many more platforms to come, having a separate driver for each
results in heavy code duplication. Also, there arises a problem of
where to put these kind of drivers ? Hence I propose the idea of having
a Current Management subsystem.
This will provide a generic ABI, API, so that the platform specific
drivers can register with this framework (and thus avail the basic
needs) and handle the events in their own way.
In simple terms, this framework will offer something like this:
Current[1-N]_limit - set of current limits
Voltage[1-X]_limit - set of voltage limits
Controllers[1-Y]_enable - These are the components by throttling/
disabling which the current consumption can be brought down.
Could you elaborate a bit more on this, perhaps by taking the Medfield
platform as an example. I don't see above any reference to timers or
maybe it's part of {Current|Voltage}[1-X]_limit?
As well, it would be nice if this system could work nicely beside
linux-iio. For example to provide the ability to plot currents and
voltages, and see when/why the actions have been taken.
Chris
With the Controllers we can follow two approaches:
A) Each component driver registers with the current framework and gets
notified when the current surge happens. On receiving the notification,
it throttles its performance. There will be a follow-up notification,
indicating that 'we are out of the high current' situation; so that
the component resumes to operation at its full performance.
B) The Current framework forwards the notification to the upper
layers and lets them decide what to do.
I agree that A) bloats the size of all the component drivers a bit,
but considering the fact that the surge has to be brought down as
soon as possible (and the delay in reacting to the event if we
pass it to the upper layers) I am inclined towards A).
I would like to see the opinion of the community on this entire
stuff, before I start writing some code.
Please Help,
Durga
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: A new Subsystem for Current Management
Hi, [snip.] > > > > I would like to see the opinion of the community on this entire > > stuff, before I start writing some code. > > looks like this should be done on hwmon ? We discussed it there. The link I sent in the previous mail, has all the discussions. Thanks, Durga -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A new Subsystem for Current Management
Hi, On Tue, Nov 08, 2011 at 04:39:17PM +0530, R, Durgadoss wrote: > [Very Sorry for the Big Email] > > [I have posted this on lm-sensors and platform-drivers-x86 > lists earlier. As per some recommendations there, posting it > here] > > As we all know, Linux is increasingly being used in handhelds. > The Hardware that supports the handhelds is also becoming > Performance-centric. With this, we need a way to efficiently > monitor the current consumption of the platform and take actions > when the platform draws more current, than it should. > > Where this can happen ? > --- > In a handheld, there are many components that demand high > Current. For example, Camera Flash, Video Streaming, 3G Voice > Call etc. Typically, two or more of these components are used > simultaneously in a real-time scenario. When this happens, the > current draw of the platform surges. If this surge lasts for > more than a specific time, it could crash the platform irrecoverably. > > How do we tackle this ? > --- > In Intel Medfield (Atom based) platform we had a driver that > Configures the current limits. When the platform current draws > more current than the programmed limit, the hardware generates > interrupt. The driver receives this interrupt and notifies the > user space to take appropriate actions. > The patch and the subsequent discussions can be found here: > http://comments.gmane.org/gmane.linux.drivers.platform.x86.devel/1197 > > To Generalize: > -- > With many more platforms to come, having a separate driver for each > results in heavy code duplication. Also, there arises a problem of > where to put these kind of drivers ? Hence I propose the idea of having > a Current Management subsystem. > > This will provide a generic ABI, API, so that the platform specific > drivers can register with this framework (and thus avail the basic > needs) and handle the events in their own way. > > In simple terms, this framework will offer something like this: > Current[1-N]_limit - set of current limits > Voltage[1-X]_limit - set of voltage limits > Controllers[1-Y]_enable - These are the components by throttling/ > disabling which the current consumption can be brought down. > > With the Controllers we can follow two approaches: > A) Each component driver registers with the current framework and gets > notified when the current surge happens. On receiving the notification, > it throttles its performance. There will be a follow-up notification, > indicating that 'we are out of the high current' situation; so that > the component resumes to operation at its full performance. > > B) The Current framework forwards the notification to the upper > layers and lets them decide what to do. > > I agree that A) bloats the size of all the component drivers a bit, > but considering the fact that the surge has to be brought down as > soon as possible (and the delay in reacting to the event if we > pass it to the upper layers) I am inclined towards A). > > I would like to see the opinion of the community on this entire > stuff, before I start writing some code. looks like this should be done on hwmon ? -- balbi signature.asc Description: Digital signature
A new Subsystem for Current Management
Hi All, [Very Sorry for the Big Email] [I have posted this on lm-sensors and platform-drivers-x86 lists earlier. As per some recommendations there, posting it here] As we all know, Linux is increasingly being used in handhelds. The Hardware that supports the handhelds is also becoming Performance-centric. With this, we need a way to efficiently monitor the current consumption of the platform and take actions when the platform draws more current, than it should. Where this can happen ? --- In a handheld, there are many components that demand high Current. For example, Camera Flash, Video Streaming, 3G Voice Call etc. Typically, two or more of these components are used simultaneously in a real-time scenario. When this happens, the current draw of the platform surges. If this surge lasts for more than a specific time, it could crash the platform irrecoverably. How do we tackle this ? --- In Intel Medfield (Atom based) platform we had a driver that Configures the current limits. When the platform current draws more current than the programmed limit, the hardware generates interrupt. The driver receives this interrupt and notifies the user space to take appropriate actions. The patch and the subsequent discussions can be found here: http://comments.gmane.org/gmane.linux.drivers.platform.x86.devel/1197 To Generalize: -- With many more platforms to come, having a separate driver for each results in heavy code duplication. Also, there arises a problem of where to put these kind of drivers ? Hence I propose the idea of having a Current Management subsystem. This will provide a generic ABI, API, so that the platform specific drivers can register with this framework (and thus avail the basic needs) and handle the events in their own way. In simple terms, this framework will offer something like this: Current[1-N]_limit - set of current limits Voltage[1-X]_limit - set of voltage limits Controllers[1-Y]_enable - These are the components by throttling/ disabling which the current consumption can be brought down. With the Controllers we can follow two approaches: A) Each component driver registers with the current framework and gets notified when the current surge happens. On receiving the notification, it throttles its performance. There will be a follow-up notification, indicating that 'we are out of the high current' situation; so that the component resumes to operation at its full performance. B) The Current framework forwards the notification to the upper layers and lets them decide what to do. I agree that A) bloats the size of all the component drivers a bit, but considering the fact that the surge has to be brought down as soon as possible (and the delay in reacting to the event if we pass it to the upper layers) I am inclined towards A). I would like to see the opinion of the community on this entire stuff, before I start writing some code. Please Help, Durga -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
