[lm-sensors] [0/6] New w1 features.

[lm-sensors] [0/6] New w1 features.

[Evgeniy Polyakov]

Ben Gardner implemented new features for w1 core
while writing a driver for the DS2482 (an i2c to w1 bridge):

1. added a new I/O function: triplet
A triplet reads two bits and writes a direction bit.  The DS2482
implements this in hardware.
I modified w1_search() to use w1_triplet() at its core.

2. cleaned up the I/O functions to separate emulated vs native w1
support.
A w1 bus master must be able to do one of:
  a. Set and sample the line via write_bit() and read_bit()
  b. Support reset_bus() and touch_bit()
Function set (a) is only needed for emulated devices (ie, a parallel
port).
He hid w1_read_bit() and w1_write_bit() behind w1_touch_bit(), and
changed functions to call touch_bit() instead or read/write_bit().
 
3. Searching is fairly slow - it requires about 200 w1 bit cycles per
device, multiplied by the number of devices on the bus.
He modified the w1_process() to NOT periodically search the bus.
A sysfs entry was added to request a search. (w1_master_search).
To request a search, echo anything into w1_master_search and it'll run
another search.

4.He added a default family so that a slave device will get reported even
if there isn't a driver for that family.

5. He wrote good documentation.

6. I wrote reconnect feature: if on start there are no
registered families all new devices will have defailt family,
later when driver for appropriate family is loaded, slaves,
which were faound earlier, will still have defult family instead 
of right one. Reconnect feature will force control thread to 
run through all master devices and all slaves found 
and search for slaves with default family id and try to reconnect
them.

Signed-off-by: Ben Gardner <bgardner@wabtec.com>
Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru>

	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

[lm-sensors] [0/6] New w1 features.

[Dmitry Torokhov]

On 6/3/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> 
> 6. I wrote reconnect feature: if on start there are no
> registered families all new devices will have defailt family,
> later when driver for appropriate family is loaded, slaves,
> which were faound earlier, will still have defult family instead
> of right one. Reconnect feature will force control thread to
> run through all master devices and all slaves found
> and search for slaves with default family id and try to reconnect
> them.

Yep, start with one kludge and you'll end up with 10 more.

Would you mind explaining why a w1 device has to be bound to a family
before it can show in sysfs? We don't have such limitation on other
buses, why is it needed for w1?

-- 
Dmitry

[lm-sensors] [0/6] New w1 features.

[Evgeniy Polyakov]

On Fri, 3 Jun 2005 16:46:48 -0500
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> On 6/3/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > 
> > 6. I wrote reconnect feature: if on start there are no
> > registered families all new devices will have defailt family,
> > later when driver for appropriate family is loaded, slaves,
> > which were faound earlier, will still have defult family instead
> > of right one. Reconnect feature will force control thread to
> > run through all master devices and all slaves found
> > and search for slaves with default family id and try to reconnect
> > them.
> 
> Yep, start with one kludge and you'll end up with 10 more.
> 
> Would you mind explaining why a w1 device has to be bound to a family
> before it can show in sysfs? We don't have such limitation on other
> buses, why is it needed for w1?

Because w1 device does not have any sence without appropriate family driver.
You may have a device without a driver for it.
All buses support it - see dmesg when new device was added but there is
no driver for that - usb bus magically says slot is used.
Here is the same.

> -- 
> Dmitry


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

[lm-sensors] [0/6] New w1 features.

[Evgeniy Polyakov]

On Sat, 4 Jun 2005 01:58:36 +0400
Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:

> On Fri, 3 Jun 2005 16:46:48 -0500
> Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> 
> > On 6/3/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > > 
> > > 6. I wrote reconnect feature: if on start there are no
> > > registered families all new devices will have defailt family,
> > > later when driver for appropriate family is loaded, slaves,
> > > which were faound earlier, will still have defult family instead
> > > of right one. Reconnect feature will force control thread to
> > > run through all master devices and all slaves found
> > > and search for slaves with default family id and try to reconnect
> > > them.
> > 
> > Yep, start with one kludge and you'll end up with 10 more.
> > 
> > Would you mind explaining why a w1 device has to be bound to a family
> > before it can show in sysfs? We don't have such limitation on other
> > buses, why is it needed for w1?
> 
> Because w1 device does not have any sence without appropriate family driver.
> You may have a device without a driver for it.
> All buses support it - see dmesg when new device was added but there is
> no driver for that - usb bus magically says slot is used.
> Here is the same.

And, btw, it is _very_ bad that other buses [not usb and not scsi at least]
do not have such reconnect feature. You can plug your device in, system
failed to detect it, and later, when you found a driver, you may not access
it from it's driver. It looks like you do not know how w1 works - there is
only one possibility to access w1 device - through appropriate bus master,
so bus muster either has to know about all devices found during the last 
search, which is currently implemented, or perform new search each time 
new device driver is added which is bogus.
Other buses support some notification about devices plugged to it, 
that is why you do not see some kind of reconnects there, w1 does not, 
so it has to reconnect.

> > -- 
> > Dmitry


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

[lm-sensors] [0/6] New w1 features.

[Dmitry Torokhov]

On 6/3/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> On Fri, 3 Jun 2005 16:46:48 -0500
> Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> 
> > On 6/3/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > >
> > > 6. I wrote reconnect feature: if on start there are no
> > > registered families all new devices will have defailt family,
> > > later when driver for appropriate family is loaded, slaves,
> > > which were faound earlier, will still have defult family instead
> > > of right one. Reconnect feature will force control thread to
> > > run through all master devices and all slaves found
> > > and search for slaves with default family id and try to reconnect
> > > them.
> >
> > Yep, start with one kludge and you'll end up with 10 more.
> >
> > Would you mind explaining why a w1 device has to be bound to a family
> > before it can show in sysfs? We don't have such limitation on other
> > buses, why is it needed for w1?
> 
> Because w1 device does not have any sence without appropriate family driver.
> You may have a device without a driver for it.
> All buses support it - see dmesg when new device was added but there is
> no driver for that - usb bus magically says slot is used.
> Here is the same.
> 

You still have not answered the question - why a family (i.e. a
driver) is needed? I have bunch of PCI devices in my box that don't
have drivers and they show up in sysfs just fine. The same with other
buses.

As it stands now you decided that you won't show devices without a
driver - then you realized that a "default" driver is needed - then
you realized that you need to reconnect when you load a "specialized"
driver. That's why I am saying start with one kludge and you'll end up
with 10 more.

-- 
Dmitry

[lm-sensors] [0/6] New w1 features.

[Dmitry Torokhov]

On 6/3/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> On Sat, 4 Jun 2005 01:58:36 +0400
> Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> 
> > On Fri, 3 Jun 2005 16:46:48 -0500
> > Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> >
> > > On 6/3/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > > >
> > > > 6. I wrote reconnect feature: if on start there are no
> > > > registered families all new devices will have defailt family,
> > > > later when driver for appropriate family is loaded, slaves,
> > > > which were faound earlier, will still have defult family instead
> > > > of right one. Reconnect feature will force control thread to
> > > > run through all master devices and all slaves found
> > > > and search for slaves with default family id and try to reconnect
> > > > them.
> > >
> > > Yep, start with one kludge and you'll end up with 10 more.
> > >
> > > Would you mind explaining why a w1 device has to be bound to a family
> > > before it can show in sysfs? We don't have such limitation on other
> > > buses, why is it needed for w1?
> >
> > Because w1 device does not have any sence without appropriate family driver.
> > You may have a device without a driver for it.
> > All buses support it - see dmesg when new device was added but there is
> > no driver for that - usb bus magically says slot is used.
> > Here is the same.
> 
> And, btw, it is _very_ bad that other buses [not usb and not scsi at least]
> do not have such reconnect feature. You can plug your device in, system
> failed to detect it, and later, when you found a driver, you may not access
> it from it's driver.

Oh, really? For some reason when I plug my USB enclosure into the port
it even loads all necessary drivers. So somehow it manages to
recognize device without having a driver for it and then, after
loading proper driver, "reconnects".

Btw, that's what my modalias patch was doing for w1 as well.

> It looks like you do not know how w1 works - there is
> only one possibility to access w1 device - through appropriate bus master,
> so bus muster either has to know about all devices found during the last
> search, which is currently implemented, or perform new search each time
> new device driver is added which is bogus.
> Other buses support some notification about devices plugged to it,
> that is why you do not see some kind of reconnects there, w1 does not,
> so it has to reconnect.

If you don't bind to a driver to begin with you don't have to reconnect, do you?

-- 
Dmitry

[lm-sensors] [0/6] New w1 features.

[Evgeniy Polyakov]

On Fri, 3 Jun 2005 17:12:16 -0500
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> On 6/3/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > On Fri, 3 Jun 2005 16:46:48 -0500
> > Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> > 
> > > On 6/3/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > > >
> > > > 6. I wrote reconnect feature: if on start there are no
> > > > registered families all new devices will have defailt family,
> > > > later when driver for appropriate family is loaded, slaves,
> > > > which were faound earlier, will still have defult family instead
> > > > of right one. Reconnect feature will force control thread to
> > > > run through all master devices and all slaves found
> > > > and search for slaves with default family id and try to reconnect
> > > > them.
> > >
> > > Yep, start with one kludge and you'll end up with 10 more.
> > >
> > > Would you mind explaining why a w1 device has to be bound to a family
> > > before it can show in sysfs? We don't have such limitation on other
> > > buses, why is it needed for w1?
> > 
> > Because w1 device does not have any sence without appropriate family driver.
> > You may have a device without a driver for it.
> > All buses support it - see dmesg when new device was added but there is
> > no driver for that - usb bus magically says slot is used.
> > Here is the same.
> > 
> 
> You still have not answered the question - why a family (i.e. a
> driver) is needed? I have bunch of PCI devices in my box that don't
> have drivers and they show up in sysfs just fine. The same with other
> buses.
> 
> As it stands now you decided that you won't show devices without a
> driver - then you realized that a "default" driver is needed - then
> you realized that you need to reconnect when you load a "specialized"
> driver. That's why I am saying start with one kludge and you'll end up
> with 10 more.

I hope you are kidding comparing PCI and w1.
lspci just shows PCI config space access.
w1 does not have nothing similar to it,
so you just may not access w1 device like you can access PCI.
In w1 there is no interrupt which can inform w1 bus master
that there is a new device like in USB.
You can only access to device using it's ID, but you must
store it somewhere or search the whole bus each time.

> -- 
> Dmitry


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

[lm-sensors] [0/6] New w1 features.

[Dmitry Torokhov]

On 6/3/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> On Fri, 3 Jun 2005 17:12:16 -0500
> Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> 
> > On 6/3/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > > On Fri, 3 Jun 2005 16:46:48 -0500
> > > Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> > >
> > > > On 6/3/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > > > >
> > > > > 6. I wrote reconnect feature: if on start there are no
> > > > > registered families all new devices will have defailt family,
> > > > > later when driver for appropriate family is loaded, slaves,
> > > > > which were faound earlier, will still have defult family instead
> > > > > of right one. Reconnect feature will force control thread to
> > > > > run through all master devices and all slaves found
> > > > > and search for slaves with default family id and try to reconnect
> > > > > them.
> > > >
> > > > Yep, start with one kludge and you'll end up with 10 more.
> > > >
> > > > Would you mind explaining why a w1 device has to be bound to a family
> > > > before it can show in sysfs? We don't have such limitation on other
> > > > buses, why is it needed for w1?
> > >
> > > Because w1 device does not have any sence without appropriate family driver.
> > > You may have a device without a driver for it.
> > > All buses support it - see dmesg when new device was added but there is
> > > no driver for that - usb bus magically says slot is used.
> > > Here is the same.
> > >
> >
> > You still have not answered the question - why a family (i.e. a
> > driver) is needed? I have bunch of PCI devices in my box that don't
> > have drivers and they show up in sysfs just fine. The same with other
> > buses.
> >
> > As it stands now you decided that you won't show devices without a
> > driver - then you realized that a "default" driver is needed - then
> > you realized that you need to reconnect when you load a "specialized"
> > driver. That's why I am saying start with one kludge and you'll end up
> > with 10 more.
> 
> I hope you are kidding comparing PCI and w1.
> lspci just shows PCI config space access.
> w1 does not have nothing similar to it,
> so you just may not access w1 device like you can access PCI.
> In w1 there is no interrupt which can inform w1 bus master
> that there is a new device like in USB.

It does not matter. Master scans wire - master finds device - master
adds device. The fact that it does not have driver (family) is
irrelevant here.

-- 
Dmitry

[lm-sensors] [0/6] New w1 features.

[Evgeniy Polyakov]

On Fri, 3 Jun 2005 17:30:45 -0500
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> On 6/3/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > On Fri, 3 Jun 2005 17:12:16 -0500
> > Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> > 
> > > On 6/3/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > > > On Fri, 3 Jun 2005 16:46:48 -0500
> > > > Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> > > >
> > > > > On 6/3/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > > > > >
> > > > > > 6. I wrote reconnect feature: if on start there are no
> > > > > > registered families all new devices will have defailt family,
> > > > > > later when driver for appropriate family is loaded, slaves,
> > > > > > which were faound earlier, will still have defult family instead
> > > > > > of right one. Reconnect feature will force control thread to
> > > > > > run through all master devices and all slaves found
> > > > > > and search for slaves with default family id and try to reconnect
> > > > > > them.
> > > > >
> > > > > Yep, start with one kludge and you'll end up with 10 more.
> > > > >
> > > > > Would you mind explaining why a w1 device has to be bound to a family
> > > > > before it can show in sysfs? We don't have such limitation on other
> > > > > buses, why is it needed for w1?
> > > >
> > > > Because w1 device does not have any sence without appropriate family driver.
> > > > You may have a device without a driver for it.
> > > > All buses support it - see dmesg when new device was added but there is
> > > > no driver for that - usb bus magically says slot is used.
> > > > Here is the same.
> > > >
> > >
> > > You still have not answered the question - why a family (i.e. a
> > > driver) is needed? I have bunch of PCI devices in my box that don't
> > > have drivers and they show up in sysfs just fine. The same with other
> > > buses.
> > >
> > > As it stands now you decided that you won't show devices without a
> > > driver - then you realized that a "default" driver is needed - then
> > > you realized that you need to reconnect when you load a "specialized"
> > > driver. That's why I am saying start with one kludge and you'll end up
> > > with 10 more.
> > 
> > I hope you are kidding comparing PCI and w1.
> > lspci just shows PCI config space access.
> > w1 does not have nothing similar to it,
> > so you just may not access w1 device like you can access PCI.
> > In w1 there is no interrupt which can inform w1 bus master
> > that there is a new device like in USB.
> 
> It does not matter. Master scans wire - master finds device - master
> adds device. The fact that it does not have driver (family) is
> irrelevant here.

I completely agree with you.
But situation remains the same - we can perform the search only
one time, and load a driver far after it. This is a feature, 
which you want to remove [again], which allows such behaviour,
without it you just drop the device and just can not recall
later about it without full rescan.

> -- 
> Dmitry


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

[lm-sensors] [0/6] New w1 features.

[Evgeniy Polyakov]

On Fri, 3 Jun 2005 17:18:25 -0500
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> On 6/3/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > On Sat, 4 Jun 2005 01:58:36 +0400
> > Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > 
> > > On Fri, 3 Jun 2005 16:46:48 -0500
> > > Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> > >
> > > > On 6/3/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > > > >
> > > > > 6. I wrote reconnect feature: if on start there are no
> > > > > registered families all new devices will have defailt family,
> > > > > later when driver for appropriate family is loaded, slaves,
> > > > > which were faound earlier, will still have defult family instead
> > > > > of right one. Reconnect feature will force control thread to
> > > > > run through all master devices and all slaves found
> > > > > and search for slaves with default family id and try to reconnect
> > > > > them.
> > > >
> > > > Yep, start with one kludge and you'll end up with 10 more.
> > > >
> > > > Would you mind explaining why a w1 device has to be bound to a family
> > > > before it can show in sysfs? We don't have such limitation on other
> > > > buses, why is it needed for w1?
> > >
> > > Because w1 device does not have any sence without appropriate family driver.
> > > You may have a device without a driver for it.
> > > All buses support it - see dmesg when new device was added but there is
> > > no driver for that - usb bus magically says slot is used.
> > > Here is the same.
> > 
> > And, btw, it is _very_ bad that other buses [not usb and not scsi at least]
> > do not have such reconnect feature. You can plug your device in, system
> > failed to detect it, and later, when you found a driver, you may not access
> > it from it's driver.
> 
> Oh, really? For some reason when I plug my USB enclosure into the port
> it even loads all necessary drivers. So somehow it manages to
> recognize device without having a driver for it and then, after
> loading proper driver, "reconnects".

:) because USB controller will catch interrupt about new device attached.
And in it's control interface new message will be put.
I repeat: w1 can not inform about new devices plugged to it, 
so we need either to poll the bus or store found devices with default "driver".

> Btw, that's what my modalias patch was doing for w1 as well.

yep. I liked your hotplug if you remember.
But you broke too many other things.

> > It looks like you do not know how w1 works - there is
> > only one possibility to access w1 device - through appropriate bus master,
> > so bus muster either has to know about all devices found during the last
> > search, which is currently implemented, or perform new search each time
> > new device driver is added which is bogus.
> > Other buses support some notification about devices plugged to it,
> > that is why you do not see some kind of reconnects there, w1 does not,
> > so it has to reconnect.
> 
> If you don't bind to a driver to begin with you don't have to reconnect, do you?

And what to do with that device when there is no driver for it.
Forget about it? This is wrong. Wait for driver and rescan the bus when it is added?
This is wrong.
Do not compare w1 with USB/scsi/PCI any other "advanced" buses, this is completely
different things, so they just can not be compared.

Dmitry, I see this discussion goes wrong way again...
Let's continue it from technical point:
you want different w1 design - like USB for example,
but it is completely wrong with w1 since 
[quite previous e-mail] we can perform the search only
one time, and load a driver far after it. This is a feature, 
which you want to remove [again], which allows such behaviour,
without it you just drop the device and just can not recall
later about it without full rescan.[/quote].

> -- 
> Dmitry


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

[lm-sensors] [0/6] New w1 features.

[Dmitry Torokhov]

On 6/3/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> 
> :) because USB controller will catch interrupt about new device attached.

It does not really matter how we discover a device. I am arguing to
what should be done once we know about it.

> 
> > Btw, that's what my modalias patch was doing for w1 as well.
> 
> yep. I liked your hotplug if you remember.
> But you broke too many other things.
> 

Not exactly, you just did not like a lot of things because you did not
want to let go of your first design.

> > If you don't bind to a driver to begin with you don't have to reconnect, do you?
> 
> And what to do with that device when there is no driver for it.
> Forget about it? This is wrong. Wait for driver and rescan the bus when it is added?
> This is wrong.

No,don;t forget. You just add a device to the bus. Without driver, that is it.

> Do not compare w1 with USB/scsi/PCI any other "advanced" buses, this is completely
> different things, so they just can not be compared.
> 
> Dmitry, I see this discussion goes wrong way again...
> Let's continue it from technical point:
> you want different w1 design - like USB for example,
> but it is completely wrong with w1 since
> [quite previous e-mail] we can perform the search only
> one time, and load a driver far after it. This is a feature,
> which you want to remove [again], which allows such behaviour,
> without it you just drop the device and just can not recall
> later about it without full rescan.[/quote].

No, that is not what I am saying or proposing to do. When you find a
device just add it to the master's bus, do not drop it. Just realize
that having a family attached to it is not required. It will be just a
device, without any attributes, sitting on the bus. When appropriate
family driver is loaded it will scan all devices (rather in-kernel
representation of them) and bind to ones it supports. Just like every
other bus.

Am I still being unclear as to what I propose?

-- 
Dmitry

[lm-sensors] [0/6] New w1 features.

[Evgeniy Polyakov]

On Fri, 3 Jun 2005 17:49:45 -0500
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> On 6/3/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > 
> > :) because USB controller will catch interrupt about new device attached.
> 
> It does not really matter how we discover a device. I am arguing to
> what should be done once we know about it.
> 
> > 
> > > Btw, that's what my modalias patch was doing for w1 as well.
> > 
> > yep. I liked your hotplug if you remember.
> > But you broke too many other things.
> > 
> 
> Not exactly, you just did not like a lot of things because you did not
> want to let go of your first design.
> 
> > > If you don't bind to a driver to begin with you don't have to reconnect, do you?
> > 
> > And what to do with that device when there is no driver for it.
> > Forget about it? This is wrong. Wait for driver and rescan the bus when it is added?
> > This is wrong.
> 
> No,don;t forget. You just add a device to the bus. Without driver, that is it.
> 
> > Do not compare w1 with USB/scsi/PCI any other "advanced" buses, this is completely
> > different things, so they just can not be compared.
> > 
> > Dmitry, I see this discussion goes wrong way again...
> > Let's continue it from technical point:
> > you want different w1 design - like USB for example,
> > but it is completely wrong with w1 since
> > [quite previous e-mail] we can perform the search only
> > one time, and load a driver far after it. This is a feature,
> > which you want to remove [again], which allows such behaviour,
> > without it you just drop the device and just can not recall
> > later about it without full rescan.[/quote].
> 
> No, that is not what I am saying or proposing to do. When you find a
> device just add it to the master's bus, do not drop it. Just realize
> that having a family attached to it is not required. It will be just a
> device, without any attributes, sitting on the bus. When appropriate
> family driver is loaded it will scan all devices (rather in-kernel
> representation of them) and bind to ones it supports. Just like every
> other bus.
> 
> Am I still being unclear as to what I propose?

It is exactly how things always worked and work now.
We have 64bit ID with some information that it is orphaned device 
[it's ->family->id = 0], so this device will be checked when new family
driver added and hopefully new attributes [which all live in one place
called w1_family] added. I called process of new attribute assignment
as "reconnection".

Exactly as you described.
 
> -- 
> Dmitry


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

[lm-sensors] [0/6] New w1 features.

[Dmitry Torokhov]

On Friday 03 June 2005 18:00, Evgeniy Polyakov wrote:
> On Fri, 3 Jun 2005 17:49:45 -0500
> Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> > On 6/3/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > > Dmitry, I see this discussion goes wrong way again...
> > > Let's continue it from technical point:
> > > you want different w1 design - like USB for example,
> > > but it is completely wrong with w1 since
> > > [quite previous e-mail] we can perform the search only
> > > one time, and load a driver far after it. This is a feature,
> > > which you want to remove [again], which allows such behaviour,
> > > without it you just drop the device and just can not recall
> > > later about it without full rescan.[/quote].
> > 
> > No, that is not what I am saying or proposing to do. When you find a
> > device just add it to the master's bus, do not drop it. Just realize
> > that having a family attached to it is not required. It will be just a
> > device, without any attributes, sitting on the bus. When appropriate
> > family driver is loaded it will scan all devices (rather in-kernel
> > representation of them) and bind to ones it supports. Just like every
> > other bus.
> > 
> > Am I still being unclear as to what I propose?
> 
> It is exactly how things always worked and work now.
> We have 64bit ID with some information that it is orphaned device 
> [it's ->family->id = 0], so this device will be checked when new family
> driver added and hopefully new attributes [which all live in one place
> called w1_family] added. I called process of new attribute assignment
> as "reconnection".
> 
> Exactly as you described.
>

*Sigh* We keep talking past each other...

What I am saying is that your decision that every W1 slave device should
be bound to a family is unfortunate one. It forces you to implement
"default" family and _add_ more code to handle switchover.

I am proposing that you allow w1 slaves with ->family = NULL and let
driver core to do the binding whenever a new family (driver) is being
registered.

Please do use driver core, we really do not need another custom driver
model in the kernel.

-- 
Dmitry

[lm-sensors] [0/6] New w1 features.

[Evgeniy Polyakov]

On Fri, 3 Jun 2005 18:42:25 -0500
Dmitry Torokhov <dtor_core@ameritech.net> wrote:

> On Friday 03 June 2005 18:00, Evgeniy Polyakov wrote:
> > On Fri, 3 Jun 2005 17:49:45 -0500
> > Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> > > On 6/3/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > > > Dmitry, I see this discussion goes wrong way again...
> > > > Let's continue it from technical point:
> > > > you want different w1 design - like USB for example,
> > > > but it is completely wrong with w1 since
> > > > [quite previous e-mail] we can perform the search only
> > > > one time, and load a driver far after it. This is a feature,
> > > > which you want to remove [again], which allows such behaviour,
> > > > without it you just drop the device and just can not recall
> > > > later about it without full rescan.[/quote].
> > > 
> > > No, that is not what I am saying or proposing to do. When you find a
> > > device just add it to the master's bus, do not drop it. Just realize
> > > that having a family attached to it is not required. It will be just a
> > > device, without any attributes, sitting on the bus. When appropriate
> > > family driver is loaded it will scan all devices (rather in-kernel
> > > representation of them) and bind to ones it supports. Just like every
> > > other bus.
> > > 
> > > Am I still being unclear as to what I propose?
> > 
> > It is exactly how things always worked and work now.
> > We have 64bit ID with some information that it is orphaned device 
> > [it's ->family->id = 0], so this device will be checked when new family
> > driver added and hopefully new attributes [which all live in one place
> > called w1_family] added. I called process of new attribute assignment
> > as "reconnection".
> > 
> > Exactly as you described.
> >
> 
> *Sigh* We keep talking past each other...

Yep...
 
> What I am saying is that your decision that every W1 slave device should
> be bound to a family is unfortunate one. It forces you to implement
> "default" family and _add_ more code to handle switchover.
> 
> I am proposing that you allow w1 slaves with ->family = NULL and let
> driver core to do the binding whenever a new family (driver) is being
> registered.

If we do not use default family [as it was] we can not know that device
exists, we can not see it in sysfs, but instead dmesg was filled with
"Family 81 is not registered" messages each tiem the same device is found.

> Please do use driver core, we really do not need another custom driver
> model in the kernel.
> 
> -- 
> Dmitry


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

[lm-sensors] [0/6] New w1 features.

[Dmitry Torokhov]

On Saturday 04 June 2005 04:50, Evgeniy Polyakov wrote:
> On Fri, 3 Jun 2005 18:42:25 -0500
> Dmitry Torokhov <dtor_core@ameritech.net> wrote:
> 
> > On Friday 03 June 2005 18:00, Evgeniy Polyakov wrote:
> > > On Fri, 3 Jun 2005 17:49:45 -0500
> > > Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> > > > On 6/3/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > > > > Dmitry, I see this discussion goes wrong way again...
> > > > > Let's continue it from technical point:
> > > > > you want different w1 design - like USB for example,
> > > > > but it is completely wrong with w1 since
> > > > > [quite previous e-mail] we can perform the search only
> > > > > one time, and load a driver far after it. This is a feature,
> > > > > which you want to remove [again], which allows such behaviour,
> > > > > without it you just drop the device and just can not recall
> > > > > later about it without full rescan.[/quote].
> > > > 
> > > > No, that is not what I am saying or proposing to do. When you find a
> > > > device just add it to the master's bus, do not drop it. Just realize
> > > > that having a family attached to it is not required. It will be just a
> > > > device, without any attributes, sitting on the bus. When appropriate
> > > > family driver is loaded it will scan all devices (rather in-kernel
> > > > representation of them) and bind to ones it supports. Just like every
> > > > other bus.
> > > > 
> > > > Am I still being unclear as to what I propose?
> > > 
> > > It is exactly how things always worked and work now.
> > > We have 64bit ID with some information that it is orphaned device 
> > > [it's ->family->id = 0], so this device will be checked when new family
> > > driver added and hopefully new attributes [which all live in one place
> > > called w1_family] added. I called process of new attribute assignment
> > > as "reconnection".
> > > 
> > > Exactly as you described.
> > >
> > 
> > *Sigh* We keep talking past each other...
> 
> Yep...
>  
> > What I am saying is that your decision that every W1 slave device should
> > be bound to a family is unfortunate one. It forces you to implement
> > "default" family and _add_ more code to handle switchover.
> > 
> > I am proposing that you allow w1 slaves with ->family = NULL and let
> > driver core to do the binding whenever a new family (driver) is being
> > registered.
> 
> If we do not use default family [as it was] we can not know that device
> exists, we can not see it in sysfs, but instead dmesg was filled with
> "Family 81 is not registered" messages each tiem the same device is found.
>

Right. So please change w1 core to _not_ drop devices if it can't find
proper family driver. Do _not_ invent dummy/default family drivers. Just
add the damn device to the bus - you know it's ID, that's all you need
to add an entry to sysfs. It is OK if it does not have any (or only has
default) attributes. When real driver binds it will create them.   

-- 
Dmitry

[lm-sensors] [0/6] New w1 features.

[Evgeniy Polyakov]

On Sat, 4 Jun 2005 11:59:18 -0500
Dmitry Torokhov <dtor_core@ameritech.net> wrote:

> On Saturday 04 June 2005 04:50, Evgeniy Polyakov wrote:
> > On Fri, 3 Jun 2005 18:42:25 -0500
> > Dmitry Torokhov <dtor_core@ameritech.net> wrote:
> > 
> > > On Friday 03 June 2005 18:00, Evgeniy Polyakov wrote:
> > > > On Fri, 3 Jun 2005 17:49:45 -0500
> > > > Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> > > > > On 6/3/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > > > > > Dmitry, I see this discussion goes wrong way again...
> > > > > > Let's continue it from technical point:
> > > > > > you want different w1 design - like USB for example,
> > > > > > but it is completely wrong with w1 since
> > > > > > [quite previous e-mail] we can perform the search only
> > > > > > one time, and load a driver far after it. This is a feature,
> > > > > > which you want to remove [again], which allows such behaviour,
> > > > > > without it you just drop the device and just can not recall
> > > > > > later about it without full rescan.[/quote].
> > > > > 
> > > > > No, that is not what I am saying or proposing to do. When you find a
> > > > > device just add it to the master's bus, do not drop it. Just realize
> > > > > that having a family attached to it is not required. It will be just a
> > > > > device, without any attributes, sitting on the bus. When appropriate
> > > > > family driver is loaded it will scan all devices (rather in-kernel
> > > > > representation of them) and bind to ones it supports. Just like every
> > > > > other bus.
> > > > > 
> > > > > Am I still being unclear as to what I propose?
> > > > 
> > > > It is exactly how things always worked and work now.
> > > > We have 64bit ID with some information that it is orphaned device 
> > > > [it's ->family->id = 0], so this device will be checked when new family
> > > > driver added and hopefully new attributes [which all live in one place
> > > > called w1_family] added. I called process of new attribute assignment
> > > > as "reconnection".
> > > > 
> > > > Exactly as you described.
> > > >
> > > 
> > > *Sigh* We keep talking past each other...
> > 
> > Yep...
> >  
> > > What I am saying is that your decision that every W1 slave device should
> > > be bound to a family is unfortunate one. It forces you to implement
> > > "default" family and _add_ more code to handle switchover.
> > > 
> > > I am proposing that you allow w1 slaves with ->family = NULL and let
> > > driver core to do the binding whenever a new family (driver) is being
> > > registered.
> > 
> > If we do not use default family [as it was] we can not know that device
> > exists, we can not see it in sysfs, but instead dmesg was filled with
> > "Family 81 is not registered" messages each tiem the same device is found.
> >
> 
> Right. So please change w1 core to _not_ drop devices if it can't find
> proper family driver. Do _not_ invent dummy/default family drivers. Just
> add the damn device to the bus - you know it's ID, that's all you need
> to add an entry to sysfs. It is OK if it does not have any (or only has
> default) attributes. When real driver binds it will create them.   

W1 core does not drop devices, it is unforgivable act for w1 with it's 
unability to inform new devices are plugged in.

We need some flag to mark _that_ device to be different from _those_ devices,
i.e. that _that_ device does not have a driver.
So now it has it's family id to be 0.
Before it has family = NULL and messages in dmesg.
I think Ben's change to support default family is right to have devices in sysfs.

You suggest to create sysfs default directory [there is only a name there]
for that device in sysfs, and it is _only_ what _is_ done for such devices.
Your suggestion _IS_ implemented :),  you just do not see it behind
"default family" and "reconnect" words.

Device has it's family id to be zero - nothing is created for sysfs 
[except default directory] or something, when driver is loaded, 
we find that device and set it's family id to be appropriate
number, so special sysfs files and attributes are added. 
 
> -- 
> Dmitry


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

[lm-sensors] [0/6] New w1 features.

[Dmitry Torokhov]

On Saturday 04 June 2005 15:18, Evgeniy Polyakov wrote:
> On Sat, 4 Jun 2005 11:59:18 -0500
> Dmitry Torokhov <dtor_core@ameritech.net> wrote:
> > 
> > Right. So please change w1 core to _not_ drop devices if it can't find
> > proper family driver. Do _not_ invent dummy/default family drivers. Just
> > add the damn device to the bus - you know it's ID, that's all you need
> > to add an entry to sysfs. It is OK if it does not have any (or only has
> > default) attributes. When real driver binds it will create them.   
> 
> W1 core does not drop devices, it is unforgivable act for w1 with it's 
> unability to inform new devices are plugged in.
> 

However thet is exactly what was going on before Ben's patch.

> We need some flag to mark _that_ device to be different from _those_ devices,
> i.e. that _that_ device does not have a driver.
> So now it has it's family id to be 0.
> Before it has family = NULL and messages in dmesg.
> I think Ben's change to support default family is right to have devices in sysfs.
> 
> You suggest to create sysfs default directory [there is only a name there]

Not really, I suggest calling device_register() and have w1 bus and
driver model/sysfs core do all necessary work for me.

> for that device in sysfs, and it is _only_ what _is_ done for such devices.
> Your suggestion _IS_ implemented :),  you just do not see it behind
> "default family" and "reconnect" words.

Yes, the result is the same, I am having an issue with implementation.
I'll try explaining my point again:

1. You made a decision that there can't be a w1_slave registered in
   with w1 core without a family driver attached - drivers w/o a driver
   get dropped.
2. Ben realized that he'd like to see devices even if there is no proper
   driver for them and introduced default family.  
3. You noticed the problem when proper driver is loaded the slave is not
   bound to it and introduced reconnect.

2 and 3 are kludges to work around of unfortunate decision 1. If you change
w1 core to register devices as they appear and bind families as needed later
you will realize that 2 and 3 are not needed at all. They just add code for
no real gain.

I do not understand why you are so resistant to converting w1 to the standard
driver model. It will work just fine with w1.

-- 
Dmitry

[lm-sensors] [0/6] New w1 features.

[Evgeniy Polyakov]

On Sat, 4 Jun 2005 22:29:22 -0500
Dmitry Torokhov <dtor_core@ameritech.net> wrote:

> On Saturday 04 June 2005 15:18, Evgeniy Polyakov wrote:
> > On Sat, 4 Jun 2005 11:59:18 -0500
> > Dmitry Torokhov <dtor_core@ameritech.net> wrote:
> > > 
> > > Right. So please change w1 core to _not_ drop devices if it can't find
> > > proper family driver. Do _not_ invent dummy/default family drivers. Just
> > > add the damn device to the bus - you know it's ID, that's all you need
> > > to add an entry to sysfs. It is OK if it does not have any (or only has
> > > default) attributes. When real driver binds it will create them.   
> > 
> > W1 core does not drop devices, it is unforgivable act for w1 with it's 
> > unability to inform new devices are plugged in.
> > 
> 
> However thet is exactly what was going on before Ben's patch.

They were reported in dmesg - information about found device was not dropped,
thought device was not in core.

> > We need some flag to mark _that_ device to be different from _those_ devices,
> > i.e. that _that_ device does not have a driver.
> > So now it has it's family id to be 0.
> > Before it has family = NULL and messages in dmesg.
> > I think Ben's change to support default family is right to have devices in sysfs.
> > 
> > You suggest to create sysfs default directory [there is only a name there]
> 
> Not really, I suggest calling device_register() and have w1 bus and
> driver model/sysfs core do all necessary work for me.
> 
> > for that device in sysfs, and it is _only_ what _is_ done for such devices.
> > Your suggestion _IS_ implemented :),  you just do not see it behind
> > "default family" and "reconnect" words.
> 
> Yes, the result is the same, I am having an issue with implementation.
> I'll try explaining my point again:
> 
> 1. You made a decision that there can't be a w1_slave registered in
>    with w1 core without a family driver attached - drivers w/o a driver
>    get dropped.
> 2. Ben realized that he'd like to see devices even if there is no proper
>    driver for them and introduced default family.  
> 3. You noticed the problem when proper driver is loaded the slave is not
>    bound to it and introduced reconnect.
> 
> 2 and 3 are kludges to work around of unfortunate decision 1. If you change
> w1 core to register devices as they appear and bind families as needed later
> you will realize that 2 and 3 are not needed at all. They just add code for
> no real gain.

It-already-is-like-you-describe :)
We can see the code:
w1_slave_found() is called with new device ID.
It searches for master and checks if this device is registered already.
If not, we go into w1_attach_slave_device().
w1_attach_slave_device():
allocates new slave device using kmalloc, fills couple of it's fields
[master, flags, regnum], initialise some paramters [completion, refcnt...],
searches for family driver for device, calls __w1_attach_slave_device().
__w1_attach_slave_device() initialises drvier, device and bus_id,
then calls device_register() and creates default sysfs file with it's name.
THAT IS ALL.
Exactly like you described :)


> I do not understand why you are so resistant to converting w1 to the standard
> driver model. It will work just fine with w1.
> 
> -- 
> Dmitry


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt