From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=wistron.com (client-ip=103.200.3.19; helo=segapp01.wistron.com; envelope-from=ben_pai@wistron.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=wistron.com Received: from segapp01.wistron.com (segapp02.wistron.com [103.200.3.19]) by lists.ozlabs.org (Postfix) with ESMTP id 49R5zz0tPjzDqQq for ; Tue, 19 May 2020 16:47:55 +1000 (AEST) Received: from EXCHAPP04.whq.wistron (unverified [10.37.38.27]) by TWNHUMSW5.wistron.com (Clearswift SMTPRS 5.6.0) with ESMTP id ; Tue, 19 May 2020 14:47:50 +0800 Received: from EXCHAPP02.whq.wistron (10.37.38.25) by EXCHAPP04.whq.wistron (10.37.38.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 19 May 2020 14:47:48 +0800 Received: from EXCHAPP02.whq.wistron ([fe80::cddc:5806:56d5:6e30]) by EXCHAPP02.whq.wistron ([fe80::cddc:5806:56d5:6e30%7]) with mapi id 15.01.1913.007; Tue, 19 May 2020 14:47:48 +0800 From: To: CC: , , , Subject: phosphor-bittware repository Thread-Topic: phosphor-bittware repository Thread-Index: AdYoOA7H2kBN2vABR5GWCd2jybLNAwEr6Iyw Date: Tue, 19 May 2020 06:47:48 +0000 Message-ID: <5c119dd93cff41c993e0a16a3717f5a4@wistron.com> Accept-Language: zh-TW, en-US Content-Language: zh-TW X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.37.38.230] x-tm-snts-smtp: 1D86CC67351C1B05CA407F4751D82519AA57FB18A7DC61F463E754BB3807B6242000:8 Content-Type: multipart/alternative; boundary="_000_5c119dd93cff41c993e0a16a3717f5a4wistroncom_" MIME-Version: 1.0 X-BeenThere: openbmc@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development list for OpenBMC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2020 06:48:00 -0000 --_000_5c119dd93cff41c993e0a16a3717f5a4wistroncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Patrick > I looked briefly at the datasheet for this hardware [1]. It appears to > expose an SMBus interface for the features you mentioned. The most > straight-forward way to get this implemented is to create a kernel > driver for most of the features you mentioned. If you implement a > driver for this hardware that interacts with the hwmon, eeprom, and LED/G= PIO > subsystems in the kernel(*), you'll be able to reuse a lot of existing > OpenBMC functionality without rewriting any userspace code. > > - Sensor > - Kernel: hwmon > - Userspace: phosphor-hwmon or dbus-sensors > - VPD > - Kernel: eeprom > - Userspace: entity-manager (I think) > - LED control > - Kernel: LED / GPIO > - Userspace: phosphor-led-manager > > The only part that wouldn't be covered would be the "Brick Protection". > We'd need to see some more information on how this is exposed but you > might be able to work it into the existing phosphor-bmc-code-mgmt > repository. For power supplies, they did create a separate repository > (phosphor-psu-code-mgmt) but I think they relied on some kernel APIs for > doing part of the work. > > (*) Depending on how the bittware hardware is implemented at an SMBus > level you may end up with multiple smaller drivers (this is better). > If there is a single SMBus address for all these functions, you'll > likely end up with one big driver. > > 1. https://www.bittware.com/wp-content/uploads/datasheets/ds-250-soc.pdf Sorry for late reply. Because the 250-soc card needs to adjust the io expander to get the relevan= t information (e.g. temperature, VPD ...). I think a dynamic detection function may be needed to handle the presence o= f the card and dynamically adjust the io expander. On the other hand, I just want to be able to integrate all the functions. Best Regards, Ben ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= --------- This email contains confidential or legally privileged information and is f= or the sole use of its intended recipient.=20 Any unauthorized review, use, copying or distribution of this email or the = content of this email is strictly prohibited. If you are not the intended recipient, you may reply to the sender and shou= ld delete this e-mail immediately. ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= --------- --_000_5c119dd93cff41c993e0a16a3717f5a4wistroncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi Patrick
 

> I looked briefly at=
 the datasheet for this hardware [1].  It appears to=



> expose an SMBus int=
erface for the features you mentioned.  The most=



> straight-forward wa=
y to get this implemented is to create a kernel


> driver for most of =
the features you mentioned.  If you implement a<=
/pre>

> driver for this har=
dware that interacts with the hwmon, eeprom, and LED/GPIO=



> subsystems in the k=
ernel(*), you'll be able to reuse a lot of existing

> OpenBMC functionali=
ty without rewriting any userspace code.


> 


> - Sensor=



>   &n=
bsp; - Kernel: hwmon


>   &n=
bsp; - Userspace: phosphor-hwmon or dbus-sensors


> - VPD


>   &n=
bsp; - Kernel: eeprom


>   &n=
bsp; - Userspace: entity-manager (I think)


> - LED control<=
/o:p>


>   &n=
bsp; - Kernel: LED / GPIO


>   &n=
bsp; - Userspace: phosphor-led-manager


> 


> The only part that =
wouldn't be covered would be the "Brick Protection".


> We'd need to see so=
me more information on how this is exposed but you

> might be able to wo=
rk it into the existing phosphor-bmc-code-mgmt


> repository.  F=
or power supplies, they did create a separate repository<=
/i>


> (phosphor-psu-code-=
mgmt) but I think they relied on some kernel APIs for=



> doing part of the w=
ork.


> 


> (*) Depending on ho=
w the bittware hardware is implemented at an SMBus

>   &n=
bsp; level you may end up with multiple smaller drivers (this is better).


>   &n=
bsp; If there is a single SMBus address for all these functions, you'll


>   &n=
bsp; likely end up with one big driver.


> 


> 1. https://www.bittware.com/wp-content/uploads/datas=
heets/ds-250-soc.pdf


 


Sorry for late reply.


 


Because the 250-soc card needs to adjust the io expander to=
 get the relevant information (e.g. temperature, VPD ...).


I think a dynamic detection function may be needed to handl=
e the presence of the card and dynamically adjust the io expander.


On the other hand, I just want to be able to integrate all =
the functions.


 


Best Regards,=



Ben


 


 

= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------

= This email contains confidential or legally privileged information and is f= or the sole use of its intended recipient.

= Any unauthorized review, use, copying or distribution of this email or the = content of this email is strictly prohibited.

= If you are not the intended recipient, you may reply to the sender and shou= ld delete this e-mail immediately.

= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------

--_000_5c119dd93cff41c993e0a16a3717f5a4wistroncom_--