Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   <Crag.Wang@dell.com>
To:     <Mario.Limonciello@dell.com>, <crag0715@gmail.com>,
        <sre@kernel.org>
CC:     <mathewk@chromium.org>, <linux-pm@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 1/1] power_supply: wilco_ec: Add permanent long life
 charging mode
Thread-Topic: [PATCH 1/1] power_supply: wilco_ec: Add permanent long life
 charging mode
Thread-Index: AQHWSTdLlppOCCC6Bki6k0A/v494M6jlsVIAgACTARD//8PXAIABEw/w
Date:   Wed, 24 Jun 2020 03:51:38 +0000
Message-ID: <23e76b5eda0849fdb4e1ef8b81807558@KULX13MDC113.APAC.DELL.COM>
References: <20200623082016.23188-1-crag_wang@dell.com>
 <6a804505400e4109906fadcf945edf76@AUSX13MPC105.AMER.DELL.COM>
 <ecda5d3852af4a1a8c08e0dc07983f35@KULX13MDC113.APAC.DELL.COM>
 <05bbf37785bd44ce8cc8777f107b16ff@AUSX13MPC105.AMER.DELL.COM>
In-Reply-To: <05bbf37785bd44ce8cc8777f107b16ff@AUSX13MPC105.AMER.DELL.COM>
Accept-Language: en-US
Content-Language: en-US
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True;
 MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd;
 MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=Mario_Limonciello@Dell.com;
 MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2020-06-23T13:48:06.9996956Z;
 MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public;
 MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure
 Information Protection;
 MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_ActionId=f22c6ecd-fc33-4d94-beba-f01c0a6f3fa5;
 MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [125.252.73.115]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216,18.0.687
 definitions=2020-06-23_17:2020-06-23,2020-06-23 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 malwarescore=0
 clxscore=1015 lowpriorityscore=0 bulkscore=0 mlxlogscore=999 mlxscore=0
 priorityscore=1501 suspectscore=0 adultscore=0 impostorscore=0
 cotscore=-2147483648 phishscore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.12.0-2004280000 definitions=main-2006240026
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0
 bulkscore=0 mlxlogscore=999 mlxscore=0 spamscore=0 adultscore=0
 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2004280000 definitions=main-2006240027
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> > > Since this is normally only done in the factory context, can you
> > > please confirm does something need to be artificially done to block
> > > userland from trying to set the battery charging to this mode?  Or
> > > will the EC already
> > handle
> > > blocking it directly?
> >
> > This is a feature of the battery, when the EC receives this setting it
> > will be sent to the battery and stored there. Afterwards any attempt
> > to change this mode will return a failure.
>=20
> Sorry this still isn't clear to me.  You're saying that if EC receives lo=
nglife
> setting it will be able to do this in the field?  If so, then I think thi=
s patch will
> need to block that setting to not allow field conversions into longlife m=
ode.
>=20
EC does handle blocking the attempts from changing the mode.

EC reads current mode ahead of a new setting. If it sees permanent long lif=
e
already in use then any attempt to put the battery charging in a different =
mode
will get failure 0x01 from EC.

> >
> > It's even better to block mode selection in the userland if long life
> > mode already in use.
>=20
> Yes, I agree.  This sounds like a good follow up to me too.