[Nut-upsdev] Add support for Ablerex Dk+ #979
Johnson-shen
johnson-shen at ablerex.com.tw
Tue Jul 27 05:24:00 BST 2021
Dear Sir,
Long time no see.
I have a question to consult you about NUT drivers.
If the driver(e.g. Ablerex_nutdrv_qx) needs to be applied to different
PID/VID, how to deal with this situation?
Besides, user or NAS selects the appropriate driver by setting ups.conf.
Is there any other way?
Regards!~
Johnson
Jim Klimov 於 5/12/2021 8:12 PM 寫道:
> On May 12, 2021 10:45:43 AM UTC, Johnson-shen <johnson-shen at ablerex.com.tw> wrote:
>> Dear sir,
>>
>> I hope you have been well!
>> May I consult with you about nutdrv_qx’s driver?
>> If we upload the new driver to NUT. (ex. Ablerex_nutdrv_qx)
>> That means we have both(blazer_USB and Ablerex_nutdrv_qx) drivers for
>> our UPS and the same PID/VID.
>> Is it correct my understanding?
>> If it is correct, when NAS manufacturers use NUT package to import to
>> their kernel. They don't know which driver to use during UPS plug-in to
>>
>> NAS. Because these two drivers have the same PID/VID (NAS vendor told
>> us
>> that they choose the driver by PID/VID).
>> Could you kindly provide more information or experience to us with
>> that?
>>
>>
>>
>> Regards!
>> Johnson
>>
>>
>>
>>
>> Johnson-shen 於 4/23/2021 11:55 AM 寫道:
>>> 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.)
> Hello,
>
> Ideally, there would be just nutdrv_qx_ablerex.c/.h source, using mostly the same code and data you developed for blazer, and no separate support in blazer at all (and so no confusion).
>
> Users (and NAS's) would configure the common nutdrv_qx driver which supports many devices related by use of Qx family of protocols and was architected to make that coexistence and re-use of shared code easy (or easier than with earlier driver codebases).
>
> Based on PID and VID and possibly strings reported to a USB query, it can pick the proper subdriver such as "ablerex" by itself, or explicitly follow the option from ups.conf section for the device.
>
> Hope this helps, and thanks,
> Jim Klimov
>
> --
> Typos courtesy of K-9 Mail on my Android
--
盈正豫順電子股份有限公司
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.)
More information about the Nut-upsdev
mailing list