New w1 features.
cover New w1 features.
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.
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
cover New w1 features.
Quoted 9 lines · Evgeniy Polyakov
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?
Signature · 1 line
Dmitry
cover New w1 features.
In reply to Evgeniy PolyakovQuoted 11 lines · On Fri, 3 Jun 2005 16:46:48 -0500 Dmitry Torokhov <[email protected]>…
Quoted 9 lines · Evgeniy Polyakov
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.
Quoted 5 lines
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.
Quoted 2 lines
Signature · 1 line
Dmitry
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
cover New w1 features.
In reply to Evgeniy PolyakovQuoted 20 lines · On Sat, 4 Jun 2005 01:58:36 +0400 Evgeniy Polyakov <[email protected]> wrote:
Quoted 11 lines · On Fri, 3 Jun 2005 16:46:48 -0500 Dmitry Torokhov <[email protected]>…
Quoted 9 lines · Evgeniy Polyakov
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.Quoted 5 lines
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?
Quoted 5 lines
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.
Quoted 2 lines
Quoted 2 lines
Signature · 1 line
Dmitry
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
cover New w1 features.
In reply to Evgeniy PolyakovQuoted 20 lines · Evgeniy Polyakov
Quoted 11 lines · On Fri, 3 Jun 2005 16:46:48 -0500 Dmitry Torokhov <[email protected]>…
Quoted 9 lines · Evgeniy Polyakov
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.Quoted 5 lines
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?
Quoted 6 lines
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.
Signature · 1 line
Dmitry
cover New w1 features.
In reply to Evgeniy PolyakovQuoted 29 lines · Evgeniy Polyakov
Quoted 20 lines · On Sat, 4 Jun 2005 01:58:36 +0400 Evgeniy Polyakov <[email protected]> wrote:
Quoted 11 lines · On Fri, 3 Jun 2005 16:46:48 -0500 Dmitry Torokhov <[email protected]>…
Quoted 9 lines · Evgeniy Polyakov
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.Quoted 5 lines
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?
Quoted 5 lines
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.
Quoted 4 lines
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.
Quoted 8 lines
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?
Signature · 1 line
Dmitry
cover New w1 features.
In reply to Evgeniy PolyakovQuoted 33 lines · On Fri, 3 Jun 2005 17:12:16 -0500 Dmitry Torokhov <[email protected]>…
Quoted 20 lines · Evgeniy Polyakov
Quoted 11 lines · On Fri, 3 Jun 2005 16:46:48 -0500 Dmitry Torokhov <[email protected]>…
Quoted 9 lines · Evgeniy Polyakov
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.Quoted 5 lines
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?
Quoted 6 lines
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.
Quoted 5 lines
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.
Quoted 2 lines
Signature · 1 line
Dmitry
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
cover New w1 features.
In reply to Evgeniy PolyakovQuoted 42 lines · Evgeniy Polyakov
Quoted 33 lines · On Fri, 3 Jun 2005 17:12:16 -0500 Dmitry Torokhov <[email protected]>…
Quoted 20 lines · Evgeniy Polyakov
Quoted 11 lines · On Fri, 3 Jun 2005 16:46:48 -0500 Dmitry Torokhov <[email protected]>…
Quoted 9 lines · Evgeniy Polyakov
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.Quoted 5 lines
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?
Quoted 6 lines
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.
Quoted 5 lines
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.
Quoted 6 lines
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.
Signature · 1 line
Dmitry
cover New w1 features.
In reply to Evgeniy PolyakovQuoted 50 lines · On Fri, 3 Jun 2005 17:30:45 -0500 Dmitry Torokhov <[email protected]>…
Quoted 42 lines · Evgeniy Polyakov
Quoted 33 lines · On Fri, 3 Jun 2005 17:12:16 -0500 Dmitry Torokhov <[email protected]>…
Quoted 20 lines · Evgeniy Polyakov
Quoted 11 lines · On Fri, 3 Jun 2005 16:46:48 -0500 Dmitry Torokhov <[email protected]>…
Quoted 9 lines · Evgeniy Polyakov
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.Quoted 5 lines
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?
Quoted 6 lines
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.
Quoted 5 lines
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.
Quoted 6 lines
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.
Quoted 3 lines
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.
Quoted 2 lines
Signature · 1 line
Dmitry
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
cover New w1 features.
In reply to Evgeniy PolyakovQuoted 35 lines · On Fri, 3 Jun 2005 17:18:25 -0500 Dmitry Torokhov <[email protected]>…
Quoted 29 lines · Evgeniy Polyakov
Quoted 20 lines · On Sat, 4 Jun 2005 01:58:36 +0400 Evgeniy Polyakov <[email protected]> wrote:
Quoted 11 lines · On Fri, 3 Jun 2005 16:46:48 -0500 Dmitry Torokhov <[email protected]>…
Quoted 9 lines · Evgeniy Polyakov
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.Quoted 5 lines
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?
Quoted 5 lines
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.Quoted 4 lines
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.
Quoted 4 lines
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".
Quoted 1 line
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.
Quoted 10 lines
Quoted 8 lines
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].
Quoted 2 lines
Signature · 1 line
Dmitry
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
cover New w1 features.
In reply to Evgeniy PolyakovQuoted 2 lines · Evgeniy Polyakov
:) 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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 5 lines
Quoted 1 line
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.
Quoted 12 lines
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?
Signature · 1 line
Dmitry
cover New w1 features.
In reply to Evgeniy PolyakovQuoted 46 lines · On Fri, 3 Jun 2005 17:49:45 -0500 Dmitry Torokhov <[email protected]>…
Quoted 2 lines · Evgeniy Polyakov
:) 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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 5 lines
Quoted 1 line
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.
Quoted 12 lines
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.
Quoted 1 line
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.
Quoted 2 lines
Signature · 1 line
Dmitry
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
cover New w1 features.
In reply to Evgeniy PolyakovQuoted 23 lines · Evgeniy Polyakov
Quoted 19 lines · On Fri, 3 Jun 2005 17:49:45 -0500 Dmitry Torokhov <[email protected]>…
Quoted 9 lines · Evgeniy Polyakov
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.
Quoted 1 line
Am I still being unclear as to what I propose?
Quoted 9 lines
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 calledw1_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.
Signature · 1 line
Dmitry
cover New w1 features.
In reply to Evgeniy PolyakovQuoted 31 lines · On Fri, 3 Jun 2005 18:42:25 -0500 Dmitry Torokhov <[email protected]>…
Quoted 30 lines · Evgeniy Polyakov
Quoted 19 lines · On Fri, 3 Jun 2005 17:49:45 -0500 Dmitry Torokhov <[email protected]>…
Quoted 9 lines · Evgeniy Polyakov
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.
Quoted 1 line
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 calledw1_family] added. I called process of new attribute assignment as "reconnection".
Quoted 4 lines
Quoted 2 lines
Exactly as you described.
*Sigh* We keep talking past each other...
Yep...
Quoted 7 lines
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.
Quoted 5 lines
Please do use driver core, we really do not need another custom driver model in the kernel.
Signature · 1 line
Dmitry
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
cover New w1 features.
In reply to Evgeniy PolyakovQuoted 45 lines · Evgeniy Polyakov
Quoted 31 lines · On Fri, 3 Jun 2005 18:42:25 -0500 Dmitry Torokhov <[email protected]>…
Quoted 30 lines · Evgeniy Polyakov
Quoted 19 lines · On Fri, 3 Jun 2005 17:49:45 -0500 Dmitry Torokhov <[email protected]>…
Quoted 9 lines · Evgeniy Polyakov
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.
Quoted 1 line
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 calledw1_family] added. I called process of new attribute assignment as "reconnection".Quoted 4 lines
Quoted 2 lines
Exactly as you described.
*Sigh* We keep talking past each other...
Yep...
Quoted 4 lines
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.
Quoted 8 lines
Quoted 3 lines
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.
Signature · 1 line
Dmitry
cover New w1 features.
In reply to Evgeniy PolyakovQuoted 55 lines · On Sat, 4 Jun 2005 11:59:18 -0500 Dmitry Torokhov <[email protected]>…
Quoted 45 lines · Evgeniy Polyakov
Quoted 31 lines · On Fri, 3 Jun 2005 18:42:25 -0500 Dmitry Torokhov <[email protected]>…
Quoted 30 lines · Evgeniy Polyakov
Quoted 19 lines · On Fri, 3 Jun 2005 17:49:45 -0500 Dmitry Torokhov <[email protected]>…
Quoted 9 lines · Evgeniy Polyakov
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.
Quoted 1 line
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 calledw1_family] added. I called process of new attribute assignment as "reconnection".Quoted 4 lines
Quoted 2 lines
Exactly as you described.
*Sigh* We keep talking past each other...
Yep...
Quoted 4 lines
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.
Quoted 8 lines
Quoted 3 lines
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.
Quoted 5 lines
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.
Quoted 2 lines
Signature · 1 line
Dmitry
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
cover New w1 features.
In reply to Evgeniy PolyakovQuoted 12 lines · Evgeniy Polyakov
Quoted 6 lines · On Sat, 4 Jun 2005 11:59:18 -0500 Dmitry Torokhov <[email protected]>…
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.
Quoted 7 lines
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.
Quoted 3 lines
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.
Signature · 1 line
Dmitry
cover New w1 features.
In reply to Evgeniy PolyakovQuoted 10 lines · On Sat, 4 Jun 2005 22:29:22 -0500 Dmitry Torokhov <[email protected]>…
Quoted 9 lines · Evgeniy Polyakov
Quoted 6 lines · On Sat, 4 Jun 2005 11:59:18 -0500 Dmitry Torokhov <[email protected]>…
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.
Quoted 5 lines
Quoted 3 lines
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.
Quoted 26 lines
Quoted 7 lines
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.Quoted 3 lines
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_slaveregistered 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.
Quoted 4 lines
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 :)
Quoted 5 lines
I do not understand why you are so resistant to converting w1 to the standard driver model. It will work just fine with w1.
Signature · 1 line
Dmitry
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt