[Nut-upsdev] Add support for Ablerex Dk+ #979
Johnson-shen
johnson-shen at ablerex.com.tw
Fri Apr 23 04:55:34 BST 2021
Dear Sirs.
I apologize for my phrase and appreciate your support and assistance for
this. We will research for drivers(nutdrv_qx).
Please Kindly support us again, if we have any questions about (nutdrv_qx).
Regards!
Johnson
Jim Klimov 於 4/20/2021 6:02 PM 寫道:
> Sorry for another delay,
>
> I was looking at recent submissions for the new-architecture
> nutdrv_qx family of drivers to provide examples, and some of those
> submissions needed a bit of cleanup before posing as examples.
> Unfortunately our QX expert did not respond yet, so it took a longer
> while on my side.
>
> So now I can suggest looking at two PRs:
> * https://github.com/networkupstools/nut/pull/638/
> <https://github.com/networkupstools/nut/pull/638/> adding support for
> "hunnox" - both a USB protocol subdriver (in nutdrv_qx.c) and
> device/HID mapping "hunnox_subdriver" (with sources in
> nutdrv_qx_hunnox.c/.h files), and
> * https://github.com/networkupstools/nut/pull/1008
> <https://github.com/networkupstools/nut/pull/1008> adding just an
> "snr" protocol subdriver at this point.
>
> They also add documentation updates for the changes they made, but
> this aspect was slightly addressed in your PR already (mention of the
> new subdriver would need to move from docs/man/blazer-common.txt to
> nutdrv_qx.txt though).
>
> To remind, my primary concerns about your original submission and
> from later discussion are:
>
> * The changes in your PR #979 are targeted for blazer_usb driver which
> would at some point be deprecated and obsoleted in favor of nutdrv_qx,
> so this added support would be lost. While someone in the community
> probably can pick up and port source code lines, it would be hard to
> guarantee without access to hardware that the resulting driver
> actually works. So in fact you are best positioned (and incentivised)
> to initially provide the modern driver that will survive in the NUT
> codebase for long.
>
> * Another point is the bold statement that "PID=0000/VID=FFFF of
> blazer_USB is Ablerex’s Identification code." It is not exactly a
> random unique number, and I suppose if the USB-IF authority had a
> *publicly* available registry of the ID numbers they give out - same
> as DNS registry, or IANA TCP/UDP port registry, or MAC address prefix
> registry for networking, or many other such lists in IT - these
> particular numbers would not be there, probably not for anyone. Since
> the USB-IF registry is not public, I can only assume that the other
> mentioned Vendor ID "1cb0" is registered properly and no other devices
> would conflict using it. I understand the technical point that these
> "0000:FFFF" are the uncustomized IDs flashed into the USB chips your
> devices use, but it also means that any other vendor might have those
> spectacularly not-unique ID numbers, with same or even unrelated
> chips. We already do have a practical example of such mess with "ATCL"
> chips that provide USB media connections for otherwise unrelated UPSes
> that talk completely different protocols and have different NUT
> drivers for same Vendor ID + Product ID + Device String tuple.
>
> * Also, "the modification is only for the addition of Ablerex product
> features, so there is no need to consider the differences of other
> customers" - the wording here may be unfortunate, English is not a
> native language for either of us, but as written this phrase looks
> very concerning :) You are changing an existing driver that supports
> several device families already, and existing users of this driver
> expect that the support is not broken when they upgrade NUT. So *OF
> COURSE* there is a need to consider differences for other customers.
> That said, your original (blazer_usb) submission was quite cleanly
> separated and should not have impacted users... unless they have some
> "0000:FFFF" device that worked before with some subdriver and would be
> detected as "ablerex_ext_command=1" and might stop working now; you
> did not offer any failsafe (addvar() a flag, probably) to override
> your detection and disable ablerex mode in the unlikely case it is
> misdiagnosed and breaks somebody in practice.
>
> * Notably, the mapping macro in nutdrv_qx is more elaborate and allows
> to map not just ID numbers but also a string the device presents
> itself with, so detection of proper subdriver can probably be made
> more reliable at that point, and not with a hack to check particular
> IDs in `blazer_initinfo()` as you proposed in current PR.
>
> Hope this helps,
> Jim Klimov
>
>
> On Mon, Apr 12, 2021 at 11:17 AM Johnson-shen
> <johnson-shen at ablerex.com.tw <mailto:johnson-shen at ablerex.com.tw>> wrote:
>
> Dear Sir,
>
> How’s today?
>
> Could you kindly provide your comment about our opinions?
>
> Please kindly provide more information, documents or example code
> about the driver that will separate Ablerex's, if you did not
> agree with our opinions.
>
>
>
> Regards!
> Johnson
>
>
>
> Johnson-shen 於 4/6/2021 6:22 PM 寫道:
>> Dear Sir,
>>
>> Could you merge our driver for us?
>> Because PID=0000/VID=FFFF of blazer_USB is Ablerex’s
>> Identification code. And this time the modification is only for
>> the addition of Ablerex product features, so there is no need to
>> consider the differences of other customers. Could you agree?
>>
>> Regards!
>> Johnson
>>
>>
>>
>> Jim Klimov 於 4/4/2021 7:43 PM 寫道:
>>> Hello,
>>>
>>> I am really sorry about the delay, I hoped our community
>>> expert on the Qx drivers would recommend the best course of
>>> action, but he did not reply yet.
>>>
>>> To me it currently seems that this Pull request:
>>> https://github.com/networkupstools/nut/pull/638/files
>>> <https://github.com/networkupstools/nut/pull/638/files>
>>> represents the modernly desirable addition of a USB protocol
>>> subdriver (in nutdrv_qx.c/.h) and the vendor protocol nuances
>>> subdriver (in separate files).
>>>
>>> Sadly, according to comment trail, that particular Pull request
>>> changed a bit of logic in existing functions (around langid_fix
>>> and enabling a hunnox patch, most prominently) and there were
>>> concerns if it is not breaking anything for other devices that
>>> work currently. It would be beneficial if people running
>>> nutdrv_qx today could build that branch and confirm into PR
>>> comments that the updated driver does work well or does break
>>> something after all.
>>>
>>> So I think the new ablerex subdriver should carefully take a
>>> similar path. Nutdrv_qx modular code did grow as a refactoring
>>> and merge of earlier drivers including blazer, so your original
>>> code contribution should be easily portable into the new layout.
>>>
>>> Thank you very much and really sorry it took longer that I'd expect,
>>> Jim Klimov
>>>
>>>
>>> On Mon, Mar 29, 2021, 13:16 Johnson-shen
>>> <johnson-shen at ablerex.com.tw
>>> <mailto:johnson-shen at ablerex.com.tw>> wrote:
>>>
>>> Dear Sir,
>>>
>>> Thank you for your reply.
>>>
>>> I can not sure what you mean.
>>>
>>> May I confirm with you again about it?
>>>
>>> You did not recommend that extend the new function from
>>> blazer_usb.c for Ablerex UPS.
>>>
>>> You suggest that separate the Ablerex function into a new
>>> driver(.c or .h) independently to avoid vendor nuances.
>>>
>>> Until we follow the above rule to modify, It will be upload
>>> and merge the driver.
>>>
>>> Is it right?
>>>
>>> Please kindly provide more information or explain to us, if
>>> I got you wrong.
>>>
>>> Please kindly provide the example for a new structure to us,
>>> I think will help to modify it for reference, if it is right.
>>>
>>> Regards!
>>> Johnson
>>>
>>>
>>>
>>>
>>> Jim Klimov 於 3/24/2021 6:26 PM 寫道:
>>>> Hello,
>>>>
>>>> Yes, in fact there were two things.
>>>>
>>>> One was that a week ago I posted some documentation updates
>>>> into your PR (e.g. for acknowledgements) and asked you to
>>>> confirm they sit well with you, and hoped that's it.
>>>>
>>>> Unfortunately, I was now reminded that extending the
>>>> blazer_usb driver was not a good approach - it was (poorly,
>>>> fixing that) documented as heading to obsoletion and
>>>> eventual removal from codebase. Various drivers for Qx
>>>> protocols were aggregated in drivers/nutdrv_qx*.{c,h} as a
>>>> common core and clean separate sources for vendor nuances.
>>>>
>>>> In order for us to maintain support for your device in the
>>>> long run, and not lose it when old redundant drivers do get
>>>> dropped, your code contribution should be relocated to this
>>>> newer structure, and importantly - re-tested with your
>>>> hardware we do not have access to. I hope Daniele (CC'ed)
>>>> can clarify this better if you would need assistance.
>>>>
>>>> Sorry about not noticing this earlier,
>>>> Jim Klimov
>>>>
>>>> On Wed, Mar 24, 2021, 03:58 Johnson-shen
>>>> <johnson-shen at ablerex.com.tw
>>>> <mailto:johnson-shen at ablerex.com.tw>> wrote:
>>>>
>>>> Dear Sir,
>>>>
>>>> The status of the project is waiting for the other
>>>> managers to verify and confirm?
>>>>
>>>> Please advise me if you have any support for this project.
>>>>
>>>>
>>>> Regards!
>>>>
>>>> Johnson
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Jim Klimov 於 3/18/2021 8:07 PM 寫道:
>>>>> Hello, thanks for the driver update and sorry that I
>>>>> had to be reminded of the PR by mailing list. I
>>>>> reviewed it last week and added a few points on
>>>>> documentation. Can you please check those, that I did
>>>>> not mistake something, and I think it is good to
>>>>> merge. Thanks again!
>>>>>
>>>>> Jim Klimov
>>>>>
>>>>> On Thu, Mar 18, 2021, 11:33 Johnson-shen
>>>>> <johnson-shen at ablerex.com.tw
>>>>> <mailto:johnson-shen at ablerex.com.tw>> wrote:
>>>>>
>>>>> Dear Wolfy,
>>>>>
>>>>> Please advise me, if you need more information
>>>>> about the new driver.
>>>>> Also please kindly update the status of the new
>>>>> driver for us.
>>>>>
>>>>> Regards!
>>>>> Johnson
>>>>>
>>>>>
>>>>>
>>>>> Johnson-shen 於 3/10/2021 6:24 PM 寫道:
>>>>>> Dear Wolfy,
>>>>>>
>>>>>> Please refer to the below table for the whole
>>>>>> support list of the UPS Model of the new driver.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Please kindly advise me if you have any questions.
>>>>>>
>>>>>> Regards!
>>>>>> Johnson
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Johnson-shen 於 3/10/2021 9:43 AM 寫道:
>>>>>>> Dear Wolfy,
>>>>>>>
>>>>>>> Thank you for the reply to emails quickly, the
>>>>>>> DK+ is our customer model name for ODM.
>>>>>>>
>>>>>>> We will provide the whole support list of UPS
>>>>>>> Model of the driver to you tomorrow.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Regards!
>>>>>>>
>>>>>>> Johnson
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Manuel Wolfshant 於 3/9/2021 7:11 PM 寫道:
>>>>>>>> On 3/9/21 8:37 AM, John wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I'm engineer from Ablere Electronics Co., Ltd.
>>>>>>>>> (http://www.ablerex.com.tw/
>>>>>>>>> <http://www.ablerex.com.tw/>).
>>>>>>>>>
>>>>>>>>> I pull request to networkupstools/nut that Add
>>>>>>>>> support for Ablerex Dk+ #979.
>>>>>>>>>
>>>>>>>>
>>>>>>>> long time user of an MS3000RT here. where is
>>>>>>>> the DK+ described? I cannot find it on your web
>>>>>>>> site or via google.
>>>>>>>>
>>>>>>>>
>>>>>>>> wolfy
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 盈正豫順電子股份有限公司
>>>>>>>
>>>>>>> Ablerex Electronics Co., Ltd.
>>>>>>>
>>>>>>> 研發部 / 沈南村
>>>>>>>
>>>>>>> E-mail:Johnson-shen at ablerex.com.tw <mailto:Johnson-shen at ablerex.com.tw>
>>>>>>>
>>>>>>> Tel: 886-7-397-8640 Ext: 894
>>>>>>>
>>>>>>> Fax: 886-7-3978641
>>>>>>>
>>>>>>> 807-66高雄市三民區水源路157號
>>>>>>>
>>>>>>> No.157, Shuiyuan Rd., Sanmin District, Kaohsiung City 807-66, Taiwan
>>>>>>> (R.O.C.)
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 盈正豫順電子股份有限公司
>>>>>>
>>>>>> Ablerex Electronics Co., Ltd.
>>>>>>
>>>>>> 研發部 / 沈南村
>>>>>>
>>>>>> E-mail:Johnson-shen at ablerex.com.tw <mailto:Johnson-shen at ablerex.com.tw>
>>>>>>
>>>>>> Tel: 886-7-397-8640 Ext: 894
>>>>>>
>>>>>> Fax: 886-7-3978641
>>>>>>
>>>>>> 807-66高雄市三民區水源路157號
>>>>>>
>>>>>> No.157, Shuiyuan Rd., Sanmin District, Kaohsiung City 807-66, Taiwan
>>>>>> (R.O.C.)
>>>>>
>>>>>
>>>>> --
>>>>> 盈正豫順電子股份有限公司
>>>>>
>>>>> Ablerex Electronics Co., Ltd.
>>>>>
>>>>> 研發部 / 沈南村
>>>>>
>>>>> E-mail:Johnson-shen at ablerex.com.tw <mailto:Johnson-shen at ablerex.com.tw>
>>>>>
>>>>> Tel: 886-7-397-8640 Ext: 894
>>>>>
>>>>> Fax: 886-7-3978641
>>>>>
>>>>> 807-66高雄市三民區水源路157號
>>>>>
>>>>> No.157, Shuiyuan Rd., Sanmin District, Kaohsiung City 807-66, Taiwan
>>>>> (R.O.C.)
>>>>>
>>>>> _______________________________________________
>>>>> Nut-upsdev mailing list
>>>>> Nut-upsdev at alioth-lists.debian.net
>>>>> <mailto:Nut-upsdev at alioth-lists.debian.net>
>>>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>>>>> <https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev>
>>>>>
>>>>
>>>> --
>>>> 盈正豫順電子股份有限公司
>>>>
>>>> Ablerex Electronics Co., Ltd.
>>>>
>>>> 研發部 / 沈南村
>>>>
>>>> E-mail:Johnson-shen at ablerex.com.tw <mailto:Johnson-shen at ablerex.com.tw>
>>>>
>>>> Tel: 886-7-397-8640 Ext: 894
>>>>
>>>> Fax: 886-7-3978641
>>>>
>>>> 807-66高雄市三民區水源路157號
>>>>
>>>> No.157, Shuiyuan Rd., Sanmin District, Kaohsiung City 807-66, Taiwan
>>>> (R.O.C.)
>>>>
>>>
>>> --
>>> 盈正豫順電子股份有限公司
>>>
>>> Ablerex Electronics Co., Ltd.
>>>
>>> 研發部 / 沈南村
>>>
>>> E-mail:Johnson-shen at ablerex.com.tw <mailto:Johnson-shen at ablerex.com.tw>
>>>
>>> Tel: 886-7-397-8640 Ext: 894
>>>
>>> Fax: 886-7-3978641
>>>
>>> 807-66高雄市三民區水源路157號
>>>
>>> No.157, Shuiyuan Rd., Sanmin District, Kaohsiung City 807-66, Taiwan
>>> (R.O.C.)
>>>
>>
>> --
>> 盈正豫順電子股份有限公司
>>
>> Ablerex Electronics Co., Ltd.
>>
>> 研發部 / 沈南村
>>
>> E-mail:Johnson-shen at ablerex.com.tw <mailto:Johnson-shen at ablerex.com.tw>
>>
>> Tel: 886-7-397-8640 Ext: 894
>>
>> Fax: 886-7-3978641
>>
>> 807-66高雄市三民區水源路157號
>>
>> No.157, Shuiyuan Rd., Sanmin District, Kaohsiung City 807-66, Taiwan
>> (R.O.C.)
>
>
> --
> 盈正豫順電子股份有限公司
>
> Ablerex Electronics Co., Ltd.
>
> 研發部 / 沈南村
>
> E-mail:Johnson-shen at ablerex.com.tw <mailto:Johnson-shen at ablerex.com.tw>
>
> Tel: 886-7-397-8640 Ext: 894
>
> Fax: 886-7-3978641
>
> 807-66高雄市三民區水源路157號
>
> No.157, Shuiyuan Rd., Sanmin District, Kaohsiung City 807-66, Taiwan
> (R.O.C.)
>
--
盈正豫順電子股份有限公司
Ablerex Electronics Co., Ltd.
研發部 / 沈南村
E-mail: Johnson-shen at ablerex.com.tw
Tel: 886-7-397-8640 Ext: 894
Fax: 886-7-3978641
807-66高雄市三民區水源路157號
No.157, Shuiyuan Rd., Sanmin District, Kaohsiung City 807-66, Taiwan
(R.O.C.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20210423/59b7b91f/attachment-0001.htm>
More information about the Nut-upsdev
mailing list