Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp2562902pxb; Mon, 17 Jan 2022 00:48:53 -0800 (PST) X-Google-Smtp-Source: ABdhPJysS70QVDn/khyVpYSR7+AeCi/ANPE9XinNXlEdHyZyg+/qHnnubisOkBADNYzO1cDjke8h X-Received: by 2002:aa7:9ecc:0:b0:4c0:aac7:59ad with SMTP id r12-20020aa79ecc000000b004c0aac759admr20006484pfq.79.1642409333179; Mon, 17 Jan 2022 00:48:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642409333; cv=none; d=google.com; s=arc-20160816; b=q8J7KBDdueFDsRwPhhXuO54iEddlg5pmJoJkXw51v+I6mcp40fHnaraU0kgL43NeB4 Xx+NalrzAKw1Op7xPIua4XJo45mClkuHZrfQ4Xm82RUio18HAmv83+a9ooyrvcsjeEHu rUk+xZmpeeVR/ZjRsLNf13sK59GRs+lvKzasSDXwTEQDBuL+SATNVvxSLjcirCl60CdF iayOhSftZq8sajLBjhuXWAGL8V3P0wefvfYFSc00bzTq5zIfXOlDd/wLESNwGtEqVTrc /Mhl4ANQytloCqrzHZRkeMz8p3QBVuLWThW4q51qWD58L0jzjVtLVVzMe+ehYDzJph1T n+0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=wd5B5q6uhmXCkTltl4oPLre+b0CAXOOsrH3DYJLPWOk=; b=qY/H93sMVSDmegExU+Fe48vXOreeQsc/KFzBQveWTjHIFvMjoki/RydtIyswfCNDpc FTkPzot5AhbIr3479PWv9X+ESWjWqgQap6Y3o47Pg7QrlOFfTxE5UNYCUgqFZAOn/Wdc lfvkAxPHM3D7ffMg7JxiuFDhHHiEdWW5jhpvopOWpJmlv8QL0TN3uhAZhnk6r8JyUuht rmnngYmIwBEzKEfYCPMSWubsGFP6dUxTVdZ0UaDMNabDxlnq5bjG7xS8Kl5AkNiWK3hg D+qpOHc8WiF/065e6EwlL11Ps7sf0TmyZ2UqEQ8vomImvJZ8Bjc+9sM7WE7pTc9aEwSg ngRw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gerhold.net header.s=strato-dkim-0002 header.b=QAyRW1Jm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v13si12043060pfm.138.2022.01.17.00.48.40; Mon, 17 Jan 2022 00:48:53 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@gerhold.net header.s=strato-dkim-0002 header.b=QAyRW1Jm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233821AbiAPQbI (ORCPT + 99 others); Sun, 16 Jan 2022 11:31:08 -0500 Received: from mo4-p01-ob.smtp.rzone.de ([85.215.255.50]:33759 "EHLO mo4-p01-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231292AbiAPQbG (ORCPT ); Sun, 16 Jan 2022 11:31:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1642350648; s=strato-dkim-0002; d=gerhold.net; h=In-Reply-To:References:Message-ID:Subject:Cc:To:From:Date:Cc:Date: From:Subject:Sender; bh=wd5B5q6uhmXCkTltl4oPLre+b0CAXOOsrH3DYJLPWOk=; b=QAyRW1JmAAA/yFoj8X3QlSMfV7J/1fZy54Yx3ak5/iNi9bBnRjTZ0qdv2HRCVFrQeH 4I9sz6VMbpxUQOhW874t2uU7b+e+pkg9hOpqKlo8sy+eGHj5CMVFdSQrAUEgNkj4ko1a +//H9KPf6J9h/viwiQOokXiVltBL/RziMlcqLcyRLAIDnTGiOFY5mqGVGmhdK+R0DkTz UbLMgs+VUrIn5piPwwXZXhDJ7ggj2l/dUCJ/ZReyuW2PRPpX2rdRpICmDN9XGTLvUGxJ 4lyglW81xWiXjBh7BIzt/MjXtU7CupYK6pceuw04NaqNn/qWpawq+FnenPnkDAgKJT5Q T5Vw== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":P3gBZUipdd93FF5ZZvYFPugejmSTVR2nRPhVOQ/OcYgojyw4j34+u267FZF9PwpcNKLVrK8+86Y=" X-RZG-CLASS-ID: mo00 Received: from gerhold.net by smtp.strato.de (RZmta 47.37.6 AUTH) with ESMTPSA id h68d06y0GGUk8zU (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Sun, 16 Jan 2022 17:30:46 +0100 (CET) Date: Sun, 16 Jan 2022 17:30:39 +0100 From: Stephan Gerhold To: Luca Weiss Cc: linux-arm-msm@vger.kernel.org, ~postmarketos/upstreaming@lists.sr.ht, phone-devel@vger.kernel.org, Vladimir Lypak , Konrad Dybcio , Andy Gross , Bjorn Andersson , Ohad Ben-Cohen , Mathieu Poirier , linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org, Srinivas Kandagatla Subject: Re: [PATCH 09/15] rpmsg: smd: Drop unnecessary condition for channel creation Message-ID: References: <20220112194118.178026-1-luca@z3ntu.xyz> <20220112194118.178026-10-luca@z3ntu.xyz> <12385151.O9o76ZdvQC@g550jk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <12385151.O9o76ZdvQC@g550jk> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jan 16, 2022 at 05:08:29PM +0100, Luca Weiss wrote: > On Mittwoch, 12. J?nner 2022 22:39:53 CET Stephan Gerhold wrote: > > On Wed, Jan 12, 2022 at 08:40:58PM +0100, Luca Weiss wrote: > > > From: Vladimir Lypak > > > > > > RPM Firmware on variety of newer SoCs such as MSM8917 (also likely > > > MSM8937, MSM8940, MSM8952), MSM8953 and on some MSM8916 devices) doesn't > > > initiate opening of the SMD channel if it was previously opened by > > > bootloader. This doesn't allow probing of smd-rpm driver on such devices > > > because there is a check that requires RPM this behaviour. > > > > > > Signed-off-by: Vladimir Lypak > > > Signed-off-by: Luca Weiss > > > Reviewed-by: Konrad Dybcio > > > > This is effectively a "Revert "Revert "rpmsg: smd: Create device for all > > channels""": > > > > https://lore.kernel.org/linux-arm-msm/20171212235857.10432-3-bjorn.andersson > > @linaro.org/ > > https://lore.kernel.org/linux-arm-msm/20180315181244.8859-1-bjorn.andersson > > @linaro.org/ > > > > Won't this cause the same regression reported by Srinivas again? > > > > Do you have any suggestion on another way to solve this? Without this commit > the regulators just won't probe at all, I haven't looked very deep into it > though given this patch solves it. > > I guess worst case it'll become a devicetree property to enable this quirk? > My spontaneous suggestion would be to skip the check only for the "rpm_requests" channel, e.g. something like if (remote_state != SMD_CHANNEL_OPENING && remote_state != SMD_CHANNEL_OPENED && strcmp(channel->name, "rpm_requests") continue; This will avoid changing the behavior for anything but the RPM channel. I don't think anything else is affected by the same problem (since the bootloader or earlier firmware should not make use of any other channel). Also, we definitely *always* want to open the channel to the RPM because otherwise almost everything breaks. Many solutions are possible though so at the end it is mostly up to Bjorn to decide I think. :) Thanks, Stephan