Received: by 10.213.65.68 with SMTP id h4csp623234imn; Wed, 4 Apr 2018 04:37:16 -0700 (PDT) X-Google-Smtp-Source: AIpwx49alq9B9hbJRIgxZ+/41Vi0Vrb+LCtZbIjAyE9/MEAhGetnIoGoUEVOipDjvj1xL5sZXakU X-Received: by 2002:a17:902:4d45:: with SMTP id o5-v6mr18783911plh.84.1522841836544; Wed, 04 Apr 2018 04:37:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522841836; cv=none; d=google.com; s=arc-20160816; b=NHjJC3SX6keXGRYU0lhj3CMi4qBOuPLDqFPQjZZnRl9rn3fHXo9r4bVq14cO1iy+Fv gpLo64Wi2xWp1s5zWrOcB+WPqxxzmwglurqcuJbnqswT1ddHkW2qKBKEPC0HppvRYOVS H1CDx+UQmDEkAAOX72AeWlvks86ntRULt7CFdBeeQU49fwxEuEfh8wQ8Vt7d4Ak54vv3 trnFGXrcFfcEPLHqKWRSgJe/6K6OiIyiwXkzIX52sVEQTIXpPMBZuze8AESB48MP1WY/ P5D742V5yU+iLYNeJrssAQaObVoI5h1y90NeXIARfU17iren0rR0kzcN7//A5WCouQ3z 8yZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=t3C80gvzk/bbRxStyzUUm22dXElns8jAXH5ZPtetzXE=; b=uh3uZRmOrGALexmQVfjzLlifBj1RCRF3Gj/aNVozk8bdCN6WmcOy60WqCQ0zH/J2M/ xgH/HLKoHgrv8MExUE0cUyH+xNMXGdzWfrTEuY+3gBU/En9XofIyb61QIoTTMvy3ooF1 o58VgZMZC1Nsz47ka7qwKjyDOh5SrIYdDScqwZy/UtQy2rCCMbOPTUcWOQdlPdKUajMA sGpMXHyZwPYO3KSvfqUtQ5bA2JBXA2zcvtb3C8zcCD6aiwaX/40Vug4SGrNlVJhSSV4W L57N+T5ghTqDyCFtLHqmz2loMW6H3AXjXoq76Gl2gyvOK35yO1588ZbvT94Fiy5ljrUr WUjw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@orpaltech.com header.s=mailru header.b=bFLKEqed; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v5si3976433pfb.179.2018.04.04.04.37.02; Wed, 04 Apr 2018 04:37:16 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@orpaltech.com header.s=mailru header.b=bFLKEqed; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751469AbeDDLfY (ORCPT + 99 others); Wed, 4 Apr 2018 07:35:24 -0400 Received: from smtp45.i.mail.ru ([94.100.177.105]:53488 "EHLO smtp45.i.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751178AbeDDLfX (ORCPT ); Wed, 4 Apr 2018 07:35:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=orpaltech.com; s=mailru; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=t3C80gvzk/bbRxStyzUUm22dXElns8jAXH5ZPtetzXE=; b=bFLKEqed92Z96cGOGvC4jPJa8I+cjEUQQsd4ro0G4ezLi0wnVImYL2o07K22/muDQY/M4qyMw6HguwSYc6E0/nKme4ndkT+T6CXpTUJ3s2bL4NnsZXAiVhrsHvPOlKu0hJXufzMxXiCUKqdO961j3sJWtmvfwfO9m9rnoxdo700=; Received: by smtp45.i.mail.ru with esmtpa (envelope-from ) id 1f3ghE-0004mZ-96; Wed, 04 Apr 2018 14:35:20 +0300 Subject: Re: [PATCH v3 3/6] spi: sun6i: restrict transfer length in PIO-mode To: Maxime Ripard Cc: Mark Brown , Chen-Yu Tsai , linux-spi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20180403154449.2443-1-ssuloev@orpaltech.com> <20180403154449.2443-4-ssuloev@orpaltech.com> <20180404065048.n76r3ytuznd6fqsl@flea> From: Sergey Suloev Message-ID: Date: Wed, 4 Apr 2018 14:35:14 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180404065048.n76r3ytuznd6fqsl@flea> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Authentication-Results: smtp45.i.mail.ru; auth=pass smtp.auth=ssuloev@orpaltech.com smtp.mailfrom=ssuloev@orpaltech.com X-7FA49CB5: 0D63561A33F958A584D384FF4120F57C4FDD0C9D9CA0A4F41F42DF47398C4A6D725E5C173C3A84C30584FF81F342DA077EE3DB2D7E8B7BCD8734EF69C36C4A4DC4224003CC836476C0CAF46E325F83A50BF2EBBBDD9D6B0F05F538519369F3743B503F486389A921A5CC5B56E945C8DA X-Mailru-Sender: C5364AD02485212F3ACDC11E67D849172C00BBB529864AC37D68A79E5987C285069BFC61DABEEB110841D3AAAB1726C63DDE9B364B0DF289264D2CD8C2503E8C22A194DADEED8EEDCA01A23BA9CD1BE7ED14614B50AE0675 X-Mras: OK Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/04/2018 09:50 AM, Maxime Ripard wrote: > On Tue, Apr 03, 2018 at 06:44:46PM +0300, Sergey Suloev wrote: >> There is no need to handle 3/4 empty interrupt as the maximum >> supported transfer length in PIO mode is equal to FIFO depth, >> i.e. 128 bytes for sun6i and 64 bytes for sun8i SoCs. >> >> Changes in v3: >> 1) Restored processing of 3/4 FIFO full interrupt. >> >> Signed-off-by: Sergey Suloev >> --- >> drivers/spi/spi-sun6i.c | 41 +++++++++++++++++------------------------ >> 1 file changed, 17 insertions(+), 24 deletions(-) >> >> diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c >> index 78acc1f..c09ad10 100644 >> --- a/drivers/spi/spi-sun6i.c >> +++ b/drivers/spi/spi-sun6i.c >> @@ -207,7 +207,10 @@ static void sun6i_spi_set_cs(struct spi_device *spi, bool enable) >> >> static size_t sun6i_spi_max_transfer_size(struct spi_device *spi) >> { >> - return SUN6I_MAX_XFER_SIZE - 1; >> + struct spi_master *master = spi->master; >> + struct sun6i_spi *sspi = spi_master_get_devdata(master); >> + >> + return sspi->fifo_depth; > Doesn't that effectively revert 3288d5cb40c0 ? > > Why do you need to do so? Need what? Change is supposed to restrict max transfer size for PIO mode otherwise it will fail. The maximum transfer length = FIFO depth for PIO mode. > >> } >> >> static int sun6i_spi_prepare_message(struct spi_master *master, >> @@ -255,8 +258,14 @@ static int sun6i_spi_transfer_one(struct spi_master *master, >> int ret = 0; >> u32 reg; >> >> - if (tfr->len > SUN6I_MAX_XFER_SIZE) >> - return -EINVAL; >> + /* A zero length transfer never finishes if programmed >> + in the hardware */ > Improper comment style here. Please make sure to run checkpatch before > sending your patches. ok > >> + if (!tfr->len) >> + return 0; > Can that case even happen? Not sure, just for safety. > >> + /* Don't support transfer larger than the FIFO */ >> + if (tfr->len > sspi->fifo_depth) >> + return -EMSGSIZE; > You're changing the return type, why? As? a more appropriate one > >> reinit_completion(&sspi->done); >> sspi->tx_buf = tfr->tx_buf; >> @@ -278,8 +287,7 @@ static int sun6i_spi_transfer_one(struct spi_master *master, >> */ >> trig_level = sspi->fifo_depth / 4 * 3; >> sun6i_spi_write(sspi, SUN6I_FIFO_CTL_REG, >> - (trig_level << SUN6I_FIFO_CTL_RF_RDY_TRIG_LEVEL_BITS) | >> - (trig_level << SUN6I_FIFO_CTL_TF_ERQ_TRIG_LEVEL_BITS)); >> + (trig_level << SUN6I_FIFO_CTL_RF_RDY_TRIG_LEVEL_BITS)); >> >> >> reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG); >> @@ -343,11 +351,8 @@ static int sun6i_spi_transfer_one(struct spi_master *master, >> sun6i_spi_fill_fifo(sspi, sspi->fifo_depth); >> >> /* Enable the interrupts */ >> - sun6i_spi_write(sspi, SUN6I_INT_CTL_REG, SUN6I_INT_CTL_TC); >> sun6i_spi_enable_interrupt(sspi, SUN6I_INT_CTL_TC | >> SUN6I_INT_CTL_RF_RDY); >> - if (tx_len > sspi->fifo_depth) >> - sun6i_spi_enable_interrupt(sspi, SUN6I_INT_CTL_TF_ERQ); > This would also need to be explained in your commit log. What exactly and in what way ? > >> >> /* Start the transfer */ >> reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG); >> @@ -376,7 +381,9 @@ out: >> static irqreturn_t sun6i_spi_handler(int irq, void *dev_id) >> { >> struct sun6i_spi *sspi = dev_id; >> - u32 status = sun6i_spi_read(sspi, SUN6I_INT_STA_REG); >> + u32 status; >> + >> + status = sun6i_spi_read(sspi, SUN6I_INT_STA_REG); > Why is this change needed? A minor one, for readability. > > Maxime >