Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <4b6a7c07-ddee-38c3-fae5-b5df6a633d83@intel.com>
Date:   Wed, 29 Mar 2023 17:11:26 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Firefox/102.0 Thunderbird/102.8.0
Subject: Re: [PATCH v1 0/6] PolarFire SoC Auto Update Support
Content-Language: en-US
To:     Conor Dooley <conor@kernel.org>
CC:     Conor Dooley <conor.dooley@microchip.com>,
        Xu Yilun <yilun.xu@intel.com>,
        Daire McNamara <daire.mcnamara@microchip.com>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Moritz Fischer <mdf@kernel.org>, Wu Hao <hao.wu@intel.com>,
        Tom Rix <trix@redhat.com>, <linux-riscv@lists.infradead.org>,
        <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <linux-fpga@vger.kernel.org>
References: <20230217164023.14255-1-conor@kernel.org>
 <Y/ht1eHgtRrLxIhC@yilunxu-OptiPlex-7050> <Y/h1KFGSw13OabYw@wendy>
 <21bebf9d-eb27-5607-b0a9-274c46ef8aa3@intel.com> <Y/0r1aR6Wik2KYBd@spud>
 <cc6176cb-6792-ef11-f42a-d2d5b12d04b4@intel.com> <Y/01B4hCOs9JPfR8@spud>
 <bd80cf70-5545-4830-a4f4-7c4f79212f68@spud>
From:   Russ Weight <russell.h.weight@intel.com>
In-Reply-To: <bd80cf70-5545-4830-a4f4-7c4f79212f68@spud>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eG9UdDJqK05aWVRrc1JkcmwxMGU1dHlhK3FFZDBiWnhkejFxQ0lZWnhZbmZX?=
 =?utf-8?B?Z2NLZkRMdE53NHNtZkNYdkV2V01jSnJ4VGlaZEhYZWRzdmZ6aWNxYkJuY3Rq?=
 =?utf-8?B?eXgzSGI0YUYwclp1RVZYd1ZSakppSE45T0lSRmdONEJzVkRNUHROZjFqcVdK?=
 =?utf-8?B?WGJsdTNmU3MrZ1BLMFFpTUV6VWFSUEdXVkVOLzM1elBMYXRGNUlDc1cyQzFW?=
 =?utf-8?B?SWxmbkc3WEF1Vmx1WDd3RE5YWXVyaXZ2aDRyVi8ycGZ0cHhTeGVET2tGV3lw?=
 =?utf-8?B?UTNjTy84T09YUzIwaUZwNFBsbmRiOGY2bVpEdjI3Mnh1Z3VQbi9BL3ZFOTA5?=
 =?utf-8?B?N0hSZStQSjJMZ3R0b2VCTHQ1Um9HaWIrdXFRNjJyQkF6c3BJYXRySXZwMkZP?=
 =?utf-8?B?R3g4aDNMeU9hT0V6eUVTQTFpd09wQlltYk5rTzBLWHhQTHZieFBUZG1vUURI?=
 =?utf-8?B?UmdBZHNaYzRXRlZlT3lIWDFFQXpoSi9RVjl5T1BHMmMrcW1JeHNTY3loVnIr?=
 =?utf-8?B?Y1ZGNFRneHRlOCtpYlJ2WFZENXRKc2lta084WGV0QkpoQTVQS1lIbk51RXBI?=
 =?utf-8?B?V0crOEJJUUxjcERjdW56QzVMa05Ta2dOU2dKcm5TMFBWMkozbkhGZE9qWS9o?=
 =?utf-8?B?WmtxcFN4MFRnbjJ5cC9Cb004ZHAvSU1HQ3pBS21QYlZpaWFFM3JQaVFhS2xM?=
 =?utf-8?B?WnFrR1lZeStKM01PUkNoS1IxUnVES09vaGF6aG9EQVFmVzFFWld2cnhiQldn?=
 =?utf-8?B?aWI0aVlGZ0p2ZVh2WlByMDVQVzJCeUFXYXBHeHhNdm1zZ3lpSzgrRHhQcWdV?=
 =?utf-8?B?VURWcm5EK3Y0UVltUGZGWTRNck45TEd5TjlNM2lya1NMZ2RJdms3NTJCZmN6?=
 =?utf-8?B?M0pQK3VzcUhWZUlWMzhEdU02TE5oTG9WalBZSXpLS0dmZ2NKMTdNYWt3QmYr?=
 =?utf-8?B?aTJOKzFrZzNuVjFwSzVYY2hzQWFvMEoycHVLY0FhQllFaEVPQXpiNm5aaGJo?=
 =?utf-8?B?NE5EaC9pSm80cmRlOG5CY2pUNm9QbldmYTVaaGJxY0hIajl5dVFUaTU0Qytk?=
 =?utf-8?B?Z3ptSUtNYnVHRldYWXFLdi95Yk9uZzNDbitWdmQxMUc1Ymp6dmZKcVN0SXp3?=
 =?utf-8?B?ODJKeFFBMDlBVkRLR3UvVUlqUDZ0dkVqTExtNHdVNmdJTFBoOHhFcmNiVVlD?=
 =?utf-8?B?Tko5cGZqOUlueVA4ZUg4ZXJpWnFKK2pDSHM2bzlWa05TWlI0SzhOdy9nTjJ4?=
 =?utf-8?B?S1c4SGVrdVVrSEhYdlN1NHQ1MDQ1RXQvNkxEdWhEVG0xendKOTFlczBrYXBz?=
 =?utf-8?B?UWdaT0doZTA2Z3FVU0E5U0w3QlZJYXVTZFZRRnhaYVpjUkFJTzNDTnR2VkE0?=
 =?utf-8?B?WkJrWld4eWYxVUJ2dS9jemhFd2xsODIvYlZIOE5vVmVmVkJzeGsxS2ZDNHFx?=
 =?utf-8?B?TW5Dc1FjTUI1TDBiVE1BOHRmZ3NYVXczTXlrWldXdjQ2YURnamU5ME5idUJ4?=
 =?utf-8?B?Z1B6eVB5SmI3YjNTaU90UHExWmV2enB3L1FRYitjcExrMnN2aldTdXlIeDMy?=
 =?utf-8?B?enNFUmxvTVRwSE9FNEFmUG1JSmlHdjRLN2U5V0lPV2lESTN1VEgzOVR4ajZu?=
 =?utf-8?B?Zk9RZVk2dWRZREVBUXhwak4rZnJhNlBmVzdEL05nYXZyaDNGVHVLYkd5Wmt3?=
 =?utf-8?B?Y1Uvc0ZWVmJVTCtxdkswRGNhNS9USkNDYWd1RFpRUXQzb213V1BZYnRoemZK?=
 =?utf-8?B?ZHdFem5FU0c4TXExTkJoTFhsSUlHd3BvcnhDcEx5eWpqT3J2UWswNWg1Zjhv?=
 =?utf-8?B?WVNCMFhkUXNEZlBYZmxzbDhjeGgxdDY1SXF2NmQ3WUN4bWU0STJGb0xLN1Vn?=
 =?utf-8?B?ckJmOENOUmRsajQyY0pYZVl3c2xJQW9LZ3Y0NC9COHp6cEdKK3plU09DeEpS?=
 =?utf-8?B?RzlIcmtYaGF6U0RhekR0MyszVnJPc0ltK1hGTTZMTjhsNVFVdU9Oc0ZUeTR0?=
 =?utf-8?B?VkYvd3dvMjFnQW1oT3NnQXA2dFdnNDdtL000aUFKZlJ6OTB5WHIxam81ekVt?=
 =?utf-8?B?amE2MUhFcGZsYXQ5ZUZ2dlhFZDV2MWxRQlJTUkxwRDdIUDV4MHY5RHJZSE1m?=
 =?utf-8?B?em1FSk1ucnpRaHJtMHVzVk9CNXJ2M3hGMWtpMjQwNGpkc2hhKzB3cDRKN0JF?=
 =?utf-8?B?QkE9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: ac283286-30ae-4e8e-53b3-08db30b34f02
X-MS-Exchange-CrossTenant-AuthSource: MW4PR11MB6763.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Mar 2023 00:11:28.8049
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: /PcUvKwQI105VhM4yMN58lVPou23oeswu2tCuNyrlC4oh91qr3b2SJGCvBdymSl/t2Px3zUoAGdGbyT1gd360a0pDeKjwVeRbGYeLOEySaY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR11MB7829
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_MED,
        SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no
        version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Conor,

Sorry for the slow reply - I was out of the office for a week...

On 3/22/23 11:51, Conor Dooley wrote:
> Hey Russ,
>
> On Mon, Feb 27, 2023 at 10:56:07PM +0000, Conor Dooley wrote:
>> On Mon, Feb 27, 2023 at 02:42:30PM -0800, Russ Weight wrote:
>>> On 2/27/23 14:16, Conor Dooley wrote:
>>>> On Mon, Feb 27, 2023 at 02:04:36PM -0800, Russ Weight wrote:
>>>>> On 2/24/23 00:28, Conor Dooley wrote:
>>>>>> On Fri, Feb 24, 2023 at 03:57:09PM +0800, Xu Yilun wrote:
>>>>>>> On 2023-02-17 at 16:40:17 +0000, Conor Dooley wrote:
>>>>>>>> This patchset adds support for the "Auto Update" feature on PolarFire
>>>>>>>> SoC that allows for writing an FPGA bistream to the SPI flash connected
>>>>>>>> to the system controller.
>>>>>>> I haven't fully checked the patches yet, just some quick comments:
>>>>>>>
>>>>>>> Since this feature is just to R/W the flash, and would not affect the
>>>>>>> runtime FPGA region, I don't think an FPGA manager is actually needed.
>>>>>>> Why not just use the MTD uAPI? There is a set of exsiting MTD uAPI &
>>>>>>> MTD tool if I remember correctly.
>>>>>> A lack of interest in opening up the system controller to userspace!
>>>>>> You're right in that the writing of the image can be done that way, and
>>>>>> while I was testing I used the userspace bits of mtd along the way - but
>>>>>> for validating that the image we are writing we rely on the system
>>>>>> controller.
>>>>>> I'm really not interested in exposing the system controller's
>>>>>> functionality, especially the bitstream manipulation parts, to userspace
>>>>>> due to the risk of input validation bugs, so at least that side of
>>>>>> things should remain in the kernel.
>>>>>> I suppose I could implement something custom in drivers/soc that does
>>>>>> the validation only, and push the rest out to userspace. Just seemed
>>>>>> fitting to do the whole lot in drivers/fpga.
>>>>> In case you haven't already looked at the new firmware-upload
>>>>> support in the firmware-loader, I'll give you some references
>>>>> here to see if it fit you needs. This would only support the
>>>>> write (not the read) but it would allow the controller to do
>>>>> validation on the write.
>>>>>
>>>>> The is the cover letter which shows a usage example:
>>>>> https://lore.kernel.org/lkml/20220421212204.36052-1-russell.h.weight@intel.com/
>>>>>
>>>>> And this is a pointer to the latest documentation for it:
>>>>> https://docs.kernel.org/driver-api/firmware/fw_upload.html
>>>>>
>>>>> The only current user is: drivers/fpga/intel-m10-bmc-sec-update.c
>>>> Sounds interesting, I shall go and take a look. Just quickly, when you
>>>> say it wouldn't support the read, what exactly do you mean?
>>>> The only read that I am really interested in doing is reading the first
>>>> 1K of flash as I need to RMW it, but I don't think that that's what you
>>>> mean.
>>>> Do you mean that I would not be able to dump the firmware using your
>>>> fw_upload interface? If so, that's an acceptable constraint IMO.
>>> Yes - I mean that you couldn't dump the firmware image from userspace
>>> using the fw_upload interface. The sysfs interface allows you to read
>>> and write a temporary buffer, but once you "echo 0 > loading", there
>>> is no sysfs interface associated with the firmware-loader that would
>>> allow you to read the image from flash. Your controller actually does
>>> the writes, so RMW in that context is fine.
>> Ahh cool. I don't really care about dumping the firmware via such a
>> mechanism, so that sounds good to me.
>> I'll check out your approach, the immediate thought is that it sounds
>> suitable to my use case, so thanks!
> Taken me a while to get around to it, but thanks for your suggestion.
> Looks like it is suitable for what I am trying to do, so in the middle
> of working on another version of this using fw_upload.
> The enum return codes from write are a little clumsy, but oh well, could
> be worse I suppose.
>
> Just one thing I noted (although I rarely pay much attention to/rely on
> the driver-api docs when recent drivers exist as usable examples) is
> that the docs for this stuff is a wee bit out of date due to some API
> changes.
> In the code example in this document:
> https://docs.kernel.org/driver-api/firmware/fw_upload.html
> firmware_upload_register() has fewer arguments than it does when you
> look at the signature of the function in the documentation right below
> it.

I saw your patch to fix this. Thanks!

- Russ
>
> Cheers,
> Conor.