Received-SPF: pass (google.com: domain of linux-kernel+bounces-127381-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <e78382b5-428e-4de8-be0d-b319534238f1@quicinc.com>
Date: Tue, 2 Apr 2024 12:34:33 +0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] bus: mhi: host: Add sysfs entry to force device to enter
 EDL
Content-Language: en-US
To: Jeffrey Hugo <quic_jhugo@quicinc.com>,
        Manivannan Sadhasivam
	<mani@kernel.org>
CC: <mhi@lists.linux.dev>, <linux-arm-msm@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <quic_cang@quicinc.com>,
        <quic_mrana@quicinc.com>, Bhaumik Bhatt <quic_bbhatt@quicinc.com>
References: <1703490474-84730-1-git-send-email-quic_qianyu@quicinc.com>
 <cff4b828-9566-a2bd-287a-138d74a76a59@quicinc.com>
 <20240102165229.GC4917@thinkpad>
 <90c0a654-a02f-46e2-96a9-34f6a30c95a0@quicinc.com>
 <a10439f1-0fcd-834c-12a3-677976529cf1@quicinc.com>
From: Qiang Yu <quic_qianyu@quicinc.com>
In-Reply-To: <a10439f1-0fcd-834c-12a3-677976529cf1@quicinc.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit


On 1/12/2024 3:08 AM, Jeffrey Hugo wrote:
> On 1/9/2024 2:20 AM, Qiang Yu wrote:
>>
>> On 1/3/2024 12:52 AM, Manivannan Sadhasivam wrote:
>>> On Tue, Jan 02, 2024 at 08:31:15AM -0700, Jeffrey Hugo wrote:
>>>> On 12/25/2023 12:47 AM, Qiang Yu wrote:
>>>>> From: Bhaumik Bhatt <quic_bbhatt@quicinc.com>
>>>>>
>>>>> Forcing the device (eg. SDX75) to enter Emergency Download Mode 
>>>>> involves
>>>>> writing the 0xEDEDEDED cookie to the channel 91 doorbell register and
>>>>> forcing an SOC reset afterwards. Allow users of the MHI bus to 
>>>>> exercise the
>>>>> sequence using a sysfs entry.
>>>> I don't see this documented in the spec anywhere.  Is this standard 
>>>> behavior
>>>> for all MHI devices?
>>>>
>>>> What about devices that don't support EDL mode?
>>>>
>>>> How should the host avoid using this special cookie when EDL mode 
>>>> is not
>>>> desired?
>>>>
>>> All points raised by Jeff are valid. I had discussions with Hemant 
>>> and Bhaumik
>>> previously on allowing the devices to enter EDL mode in a generic 
>>> manner and we
>>> didn't conclude on one final approach.
>>>
>>> Whatever way we come up with, it should be properly described in the 
>>> MHI spec
>>> and _should_ be backwards compatible.
>>
>> Hi Mani, Jeff. The method of entering EDL mode is documented in MHI 
>> spec v1.2, Chapter 13.2.
>>
>> Could you please check once?
>
> I do see it listed there.  However that was a FR for SDX55, so devices 
> prior to that would not support this.  AIC100 predates this change and 
> would not support the functionality.  I verified the AIC100 
> implementation is not aware of this cookie.
>
> Also, that functionality depends on channel 91 being reserved per the 
> table 9-2, however that table only applies to modem class devices as 
> it is under chapter 9 "Modem protocols over PCIe". Looking at the 
> ath11k and ath12k implementations in upstream, it looks like they 
> partially comply.  Other devices have different MHI channel definitions.
>
> Chapter 9 doesn't appear to be in older versions of the spec that I 
> have, so it is unclear if this functionality is backwards compatible 
> (was channel 91 used for another purpose in pre-SDX55 modems).
>
> I'm not convinced this belongs in the MHI core.  At a minimum, the MHI 
> controller(s) for the applicable devices needs to opt-in to this.
>
> -Jeff
Hi Jeff

Sorry for reply so late. In older versions of the spec, there is no 
description about EDL doorbell. However, in MHI spec v1.2, section 13.2,
It explicitly says "To set the EDL cookie, the host writes 0xEDEDEDED to 
channel doorbell 91." So I think every device based on MHI spec v1.2
should reserve channel doorbell 91 for EDL mode.

So can we add another flag called mhi_ver in mhi controller to indicate 
its mhi version and then we can add mhi_ver checking to determine if this
device supports EDL sysfs operation?

Thanks,
Qiang