Thread: [PATCH] firewire: core: mask previous entry's type bits when looking for leaf
Brought to you by:
aeb,
bencollins
From: Adam G. <ad...@po...> - 2024-01-25 12:15:26
|
When searching a configuration ROM directory for a leaf corresponding to a specific key_ID, disregard the type bits of the directory entry. The configuration ROM of FireWire devices can contain textual descriptor leafs (strings) for vendor name and model name. We use these to populate the vendor_name and model_name entries in sysfs. Each descriptor leaf has a descriptor directory entry pointing to it. The identity of the descriptor leaf is indicated by the key_ID of the directory entry immediately before the descriptor leaf's directory entry. The key_ID is the low 6 bits of the high byte of the directory entry, and the type is the high 2 bits. In most cases, the directory entry before a descriptor directory entry will be an immediate value (type=0). However, it is also valid for it to be a directory (type=3). Thus, when looking for a specific leaf, we must mask off the type bits and compare only the key_ID. One affected device is the Sony DVMC-DA1, which is missing the vendor_name sysfs entry without this change. The recent commit 141d9c6e003b806d8faeddeec7053ee2691ea61a fixed missing model and model_name entries for the DVMC-DA1, but those were caused by a different issue. Signed-Off-By: Adam Goldman <ad...@po...> --- --- linux-6.8-rc1.orig/drivers/firewire/core-device.c 2024-01-21 14:11:32.000000000 -0800 +++ linux-6.8-rc1/drivers/firewire/core-device.c 2024-01-24 03:56:56.000000000 -0800 @@ -72,7 +72,7 @@ fw_csr_iterator_init(&ci, directory); while (fw_csr_iterator_next(&ci, &key, &value)) { - if (last_key == search_key && + if ((last_key & 0x3f) == search_key && key == (CSR_DESCRIPTOR | CSR_LEAF)) return ci.p - 1 + value; |
From: Takashi S. <o-t...@sa...> - 2024-01-26 01:17:23
|
Hi, On Thu, Jan 25, 2024 at 04:15:12AM -0800, Adam Goldman wrote: > When searching a configuration ROM directory for a leaf corresponding to > a specific key_ID, disregard the type bits of the directory entry. > > The configuration ROM of FireWire devices can contain textual descriptor > leafs (strings) for vendor name and model name. We use these to populate > the vendor_name and model_name entries in sysfs. Each descriptor leaf has a > descriptor directory entry pointing to it. The identity of the descriptor > leaf is indicated by the key_ID of the directory entry immediately before > the descriptor leaf's directory entry. The key_ID is the low 6 bits of the > high byte of the directory entry, and the type is the high 2 bits. > > In most cases, the directory entry before a descriptor directory entry will > be an immediate value (type=0). However, it is also valid for it to be a > directory (type=3). Thus, when looking for a specific leaf, we must mask > off the type bits and compare only the key_ID. > > One affected device is the Sony DVMC-DA1, which is missing the vendor_name > sysfs entry without this change. > > The recent commit 141d9c6e003b806d8faeddeec7053ee2691ea61a fixed missing > model and model_name entries for the DVMC-DA1, but those were caused by a > different issue. > > Signed-Off-By: Adam Goldman <ad...@po...> > --- > > --- linux-6.8-rc1.orig/drivers/firewire/core-device.c 2024-01-21 14:11:32.000000000 -0800 > +++ linux-6.8-rc1/drivers/firewire/core-device.c 2024-01-24 03:56:56.000000000 -0800 > @@ -72,7 +72,7 @@ > > fw_csr_iterator_init(&ci, directory); > while (fw_csr_iterator_next(&ci, &key, &value)) { > - if (last_key == search_key && > + if ((last_key & 0x3f) == search_key && > key == (CSR_DESCRIPTOR | CSR_LEAF)) > return ci.p - 1 + value; Would I request you to update the API documentation of fw_csr_string() as well and send the renewed patch as take 2? I have a mixed feeling about the change, but I'll finally accept it since we face the exception against documentation. As you know, in Annex A of document for configuration ROM of AV/C device[1], we can see the legacy layout of configuration ROM (page 22). In the layout, the descriptor leaf entry for vendor name locates after the immediate value entry for vendor ID, then the directory entry for vendor directory locates. However, in the case of Sony DVMC-DA1, the descriptor leaf entry locates after the directory entry. It is an exception. The change brings the behaviour change of fw_csr_string() since it is currently coded to pick up the text pointed by the descriptor leaf entry just after the immediate value entry. Fortunately, as long as I know, the change is safe and brings no regression. In the concept of software stack in kernel, whether the string is picked up or not is not so important, since it is just for human readability. It is just enough to pick up information to detect the relationship between node and unit and their corresponding drivers. The parse of configuration ROM should be done in userspace application again. Actually the most of userspace applications are programmed so. In the case of systemd udev/hwdb, it is not so preferable to put device-dependent code, therefore the device attributes are important in our case. But the vendor string provided by the stack is not necessarily useful since hwdb can fulfill it now[2]. ... But the above are just theories. The world has many complicated things, I know. So I accept your proposal. But note that the preferable way is to find the other devices which have the configuration ROM similar to the case. We have already implemented the support for the legacy layout of configuration ROM. It's time for you to start collecting the configuration ROMs for digital video devices, like I did for audio and music units in IEEE 1394 bus[3][4]. [1] Configuration ROM for AV/C Devices 1.0 (1394 Trading Association, Dec 2000, TA Document 1999027) https://web.archive.org/web/20210216003030/http://1394ta.org/wp-content/uploads/2015/07/1999027.pdf [2] https://github.com/systemd/systemd/pull/31054 [3] https://github.com/takaswie/am-config-roms/ [4] https://github.com/systemd/systemd/blob/main/hwdb.d/80-ieee1394-unit-function.hwdb Thanks Takashi Sakamoto |
From: Adam G. <ad...@po...> - 2024-01-26 08:49:53
|
On Fri, Jan 26, 2024 at 10:17:05AM +0900, Takashi Sakamoto wrote: > Would I request you to update the API documentation of fw_csr_string() > as well and send the renewed patch as take 2? > > > I have a mixed feeling about the change, but I'll finally accept it since > we face the exception against documentation. > > As you know, in Annex A of document for configuration ROM of AV/C > device[1], we can see the legacy layout of configuration ROM (page 22). > In the layout, the descriptor leaf entry for vendor name locates after > the immediate value entry for vendor ID, then the directory entry for > vendor directory locates. However, in the case of Sony DVMC-DA1, the > descriptor leaf entry locates after the directory entry. It is an > exception. Hi Takashi, Thank you for your review and feedback. After checking the 1394TA Configuration ROM document again, I agree that the leaf entry for vendor name should be after an immediate value entry according to this standard. The DVMC-DA1 does not conform. We should consider its configuration ROM format to be another variation of the legacy format. This variation is not mentioned in Annex A. I will update the API documentation of fw_csr_string() and send a revised patch. -- Adam |
From: Takashi S. <o-t...@sa...> - 2024-01-26 12:19:28
|
Hi, On Fri, Jan 26, 2024 at 12:49:35AM -0800, Adam Goldman wrote: > On Fri, Jan 26, 2024 at 10:17:05AM +0900, Takashi Sakamoto wrote: > > Would I request you to update the API documentation of fw_csr_string() > > as well and send the renewed patch as take 2? > > > > > > I have a mixed feeling about the change, but I'll finally accept it since > > we face the exception against documentation. > > > > As you know, in Annex A of document for configuration ROM of AV/C > > device[1], we can see the legacy layout of configuration ROM (page 22). > > In the layout, the descriptor leaf entry for vendor name locates after > > the immediate value entry for vendor ID, then the directory entry for > > vendor directory locates. However, in the case of Sony DVMC-DA1, the > > descriptor leaf entry locates after the directory entry. It is an > > exception. > > Hi Takashi, > > Thank you for your review and feedback. > > After checking the 1394TA Configuration ROM document again, I agree that > the leaf entry for vendor name should be after an immediate value entry > according to this standard. The DVMC-DA1 does not conform. We should > consider its configuration ROM format to be another variation of the > legacy format. This variation is not mentioned in Annex A. > > I will update the API documentation of fw_csr_string() and send a > revised patch. I think we can handle the quirk of configuration ROM without changing the kernel API. Would you test the following patch? (not tested in my side). ======== 8< -------- >From 83bf1e04d308ea89c76c64e3168b9701f9d9191b Mon Sep 17 00:00:00 2001 From: Takashi Sakamoto <o-t...@sa...> Date: Fri, 26 Jan 2024 20:37:21 +0900 Subject: [PATCH] firewire: search descriptor leaf just after vendor directory entry in root directory It appears that Sony DVMC-DA1 has a quirk that the descriptor leaf entry locates just after the vendor directory entry in root directory. This is not equivalent to the legacy layout of configuration ROM described in Configuration ROM for AV/C Devices 1.0 (1394 Trading Association, Dec 2000, TA Document 1999027). This commit changes current implementation to parse configuration ROM for device attributes so that the descriptor leaf entry can be detected for the vendor name. $ config-rom-pretty-printer < Sony-DVMC-DA1.img ROM header and bus information block ----------------------------------------------------------------- 1024 041ee7fb bus_info_length 4, crc_length 30, crc 59387 1028 31333934 bus_name "1394" 1032 e0644000 irmc 1, cmc 1, isc 1, bmc 0, cyc_clk_acc 100, max_rec 4 (32) 1036 08004603 company_id 080046 | 1040 0014193c device_id 12886219068 | EUI-64 576537731003586876 root directory ----------------------------------------------------------------- 1044 0006b681 directory_length 6, crc 46721 1048 03080046 vendor 1052 0c0083c0 node capabilities: per IEEE 1394 1056 8d00000a --> eui-64 leaf at 1096 1060 d1000003 --> unit directory at 1072 1064 c3000005 --> vendor directory at 1084 1068 8100000a --> descriptor leaf at 1108 unit directory at 1072 ----------------------------------------------------------------- 1072 0002cdbf directory_length 2, crc 52671 1076 1200a02d specifier id 1080 13010000 version vendor directory at 1084 ----------------------------------------------------------------- 1084 00020cfe directory_length 2, crc 3326 1088 17fa0000 model 1092 81000008 --> descriptor leaf at 1124 eui-64 leaf at 1096 ----------------------------------------------------------------- 1096 0002c66e leaf_length 2, crc 50798 1100 08004603 company_id 080046 | 1104 0014193c device_id 12886219068 | EUI-64 576537731003586876 descriptor leaf at 1108 ----------------------------------------------------------------- 1108 00039e26 leaf_length 3, crc 40486 1112 00000000 textual descriptor 1116 00000000 minimal ASCII 1120 536f6e79 "Sony" descriptor leaf at 1124 ----------------------------------------------------------------- 1124 0005001d leaf_length 5, crc 29 1128 00000000 textual descriptor 1132 00000000 minimal ASCII 1136 44564d43 "DVMC" 1140 2d444131 "-DA1" 1144 00000000 Signed-off-by: Takashi Sakamoto <o-t...@sa...> --- drivers/firewire/core-device.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/firewire/core-device.c b/drivers/firewire/core-device.c index 0547253d16fe..30a734ee9de9 100644 --- a/drivers/firewire/core-device.c +++ b/drivers/firewire/core-device.c @@ -368,8 +368,16 @@ static ssize_t show_text_leaf(struct device *dev, for (i = 0; i < ARRAY_SIZE(directories) && !!directories[i]; ++i) { int result = fw_csr_string(directories[i], attr->key, buf, bufsize); // Detected. - if (result >= 0) + if (result >= 0) { ret = result; + } else if (i == 0 && attr->key == CSR_VENDOR) { + // Sony DVMC-DA1 has configuration ROM such that the descriptor leaf entry + // in the root directory follows to the directory entry for vendor ID + // instead of the immediate value for vendor ID. + result = fw_csr_string(directories[i], CSR_DIRECTORY | attr->key, buf, bufsize); + if (result >= 0) + ret = result; + } } if (ret >= 0) { -- 2.40.1 ======== 8< -------- Regards Takashi Sakamoto |
From: Adam G. <ad...@po...> - 2024-01-27 04:54:02
|
On Fri, Jan 26, 2024 at 09:19:17PM +0900, Takashi Sakamoto wrote: > I think we can handle the quirk of configuration ROM without changing > the kernel API. Would you test the following patch? (not tested in my > side). > > ======== 8< -------- > > >From 83bf1e04d308ea89c76c64e3168b9701f9d9191b Mon Sep 17 00:00:00 2001 > From: Takashi Sakamoto <o-t...@sa...> > Date: Fri, 26 Jan 2024 20:37:21 +0900 > Subject: [PATCH] firewire: search descriptor leaf just after vendor directory > entry in root directory Hi Takashi, I tested your patch with the DVMC-DA1. I also tested it with another device with normal placement of the leaf entry. In both cases, it works. -- Adam |
From: Takashi S. <o-t...@sa...> - 2024-01-30 19:10:57
|
Hi, On Fri, Jan 26, 2024 at 08:53:42PM -0800, Adam Goldman wrote: > On Fri, Jan 26, 2024 at 09:19:17PM +0900, Takashi Sakamoto wrote: > > I think we can handle the quirk of configuration ROM without changing > > the kernel API. Would you test the following patch? (not tested in my > > side). > > > > ======== 8< -------- > > > > >From 83bf1e04d308ea89c76c64e3168b9701f9d9191b Mon Sep 17 00:00:00 2001 > > From: Takashi Sakamoto <o-t...@sa...> > > Date: Fri, 26 Jan 2024 20:37:21 +0900 > > Subject: [PATCH] firewire: search descriptor leaf just after vendor directory > > entry in root directory > > Hi Takashi, > > I tested your patch with the DVMC-DA1. I also tested it with another > device with normal placement of the leaf entry. In both cases, it works. Thanks for your test. I reposted the patch in the series of changes for v6.8-rc3[1]. The behaviour change of kernel API is not preferable within the same version of kernel once the release candidates is public, while we need to handle it as the series of changes to support the legacy layout of configuration ROM. So I'll apply my version to for-linus branch and send it to him. Anyway thanks for your work and suggestion. [1] https://lore.kernel.org/lkml/202...@sa.../ Thanks Takashi Sakamoto |