From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrzej Hajda Subject: Re: [PATCH 1/4] drm/dsi: Make mipi_dsi_dcs_write() return ssize_t Date: Wed, 23 Jul 2014 10:18:21 +0200 Message-ID: <53CF6FCD.9080805@samsung.com> References: <1406013141-18552-1-git-send-email-thierry.reding@gmail.com> <53CE12A7.1010403@samsung.com> <53CE33F7.6020204@samsung.com> <53CE3785.5080407@samsung.com> <53CE3B8B.3000503@samsung.com> <20140723072743.GD15759@ulmo.nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by gabe.freedesktop.org (Postfix) with ESMTP id C8C926E5DB for ; Wed, 23 Jul 2014 01:18:25 -0700 (PDT) Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout2.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0N9500ANIOE5ZZ00@mailout2.w1.samsung.com> for dri-devel@lists.freedesktop.org; Wed, 23 Jul 2014 09:18:05 +0100 (BST) In-reply-to: <20140723072743.GD15759@ulmo.nvidia.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Thierry Reding Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On 07/23/2014 09:27 AM, Thierry Reding wrote: > On Tue, Jul 22, 2014 at 12:23:07PM +0200, Andrzej Hajda wrote: >> Hi Thierry, >> >> YoungJun's comment refreshed my memory about mipi_dsi_dcs_write return >> value. It should be rather int than ssize_t. Why? >> .transfer() returns the number of read bytes or error, but in case >> of dcs write no bytes are read, so it in fact returns error or 0. >> This is why return value was implemented originally as int. >> So I do not think this patch is necessary. > I think it should return the number of bytes written or an error. That > way we give callers the maximum amount of information. They may still > choose to only handle < 0 for convenience, but at least the information > will be there should it become required at some point. AFAIK DSI write operation is atomic, ie either all requested bytes have been sent either there was an error and in such case we should assume no byte have been sent. Returning number of written bytes in this case is just returning length of write buffer - something caller already knows. Additionally it suggests that partial write is possible which is not true. I know it is implemented such way in i2c (which is non atomic) but the comment in i2c_transfer shows its weakness [1]. [1]: http://lxr.free-electrons.com/source/drivers/i2c/i2c-core.c#L1782 Regards Andrzej > > Thierry