From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C134AC54EE9 for ; Thu, 22 Sep 2022 11:26:50 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 210FC84CE3; Thu, 22 Sep 2022 13:26:48 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=thorsis.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=thorsis.com header.i=@thorsis.com header.b="T8+JNlaj"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id BBC5D84CEA; Thu, 22 Sep 2022 13:26:46 +0200 (CEST) Received: from mail.thorsis.com (mail.thorsis.com [92.198.35.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 0D48E84CDF for ; Thu, 22 Sep 2022 13:26:44 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=thorsis.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=ada@thorsis.com Date: Thu, 22 Sep 2022 13:26:40 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thorsis.com; s=default; t=1663846002; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:content-type:content-type:in-reply-to:in-reply-to: references:references; bh=FhVrwBkuwEngy+w4ad3V5parpplQAsVKLe/JD/AiZ70=; b=T8+JNlajhXh6jtLC5xNwpq8o2XkjccIcxfV6mkla37/oT9KbBIxk3Wzby6DQvg8x6Gyd66 9Veb5542W3vANApjmWfoJb75bLxypPbjpR8oiVrrER1lHMxJ1zIBjlTkkwvC0Xq9SjzDFJ C+Ond0IjATX2I9PkMNe04h5w28nJI01Ipg82Rv8ah0zgvEwwGZvIebBcMdWmq0h+/pNw2q VdYHVar2GpHATh3fZnXk3Es2KdBW8mljFeMOqueOiUNnjifObYgpyLh2D9ZnaNkMYOd4Bu Q9pFprL1yypIQyoKkWbiLOwENlnn+PUHjgXDaJYT1aVlZMlkpCqHvTjRwIJg4g== From: Alexander Dahl To: Michal Simek Cc: Alexander Dahl , u-boot@lists.denx.de, Simon Glass Subject: Re: [PATCH v2 8/8] fpga: virtex2: Use logging feature instead of FPGA_DEBUG Message-ID: Mail-Followup-To: Michal Simek , u-boot@lists.denx.de, Simon Glass References: <20220921132216.7089-1-ada@thorsis.com> <20220921132216.7089-9-ada@thorsis.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean Hello Michal, Am Thu, Sep 22, 2022 at 12:30:08PM +0200 schrieb Michal Simek: > > > On 9/21/22 15:22, Alexander Dahl wrote: > > Instead of using DEBUG or LOG_DEBUG the driver still had its own > > definition for debug output. > > > > Signed-off-by: Alexander Dahl > > --- > > drivers/fpga/virtex2.c | 37 +++++++++++++++---------------------- > > 1 file changed, 15 insertions(+), 22 deletions(-) > > > > diff --git a/drivers/fpga/virtex2.c b/drivers/fpga/virtex2.c > > index 51b8d31205..fddf8ac4ce 100644 > > --- a/drivers/fpga/virtex2.c > > +++ b/drivers/fpga/virtex2.c > > @@ -12,21 +12,14 @@ > > * on spartan2.c (Rich Ireland, rireland@enterasys.com). > > */ > > +#define LOG_CATEGORY UCLASS_FPGA > > + > > #include > > #include > > +#include > > #include > > #include > > -#if 0 > > -#define FPGA_DEBUG > > -#endif > > - > > -#ifdef FPGA_DEBUG > > -#define PRINTF(fmt, args...) printf(fmt, ##args) > > -#else > > -#define PRINTF(fmt, args...) > > -#endif > > - > > /* > > * If the SelectMap interface can be overrun by the processor, define > > * CONFIG_SYS_FPGA_CHECK_BUSY and/or CONFIG_FPGA_DELAY in the board > > @@ -89,12 +82,12 @@ static int virtex2_load(xilinx_desc *desc, const void *buf, size_t bsize, > > switch (desc->iface) { > > case slave_serial: > > - PRINTF("%s: Launching Slave Serial Load\n", __func__); > > + log_debug("%s: Launching Slave Serial Load\n", __func__); > > ret_val = virtex2_ss_load(desc, buf, bsize); > > break; > > case slave_selectmap: > > - PRINTF("%s: Launching Slave Parallel Load\n", __func__); > > + log_debug("%s: Launching Slave Parallel Load\n", __func__); > > ret_val = virtex2_ssm_load(desc, buf, bsize); > > break; > > @@ -111,12 +104,12 @@ static int virtex2_dump(xilinx_desc *desc, const void *buf, size_t bsize) > > switch (desc->iface) { > > case slave_serial: > > - PRINTF("%s: Launching Slave Serial Dump\n", __func__); > > + log_debug("%s: Launching Slave Serial Dump\n", __func__); > > ret_val = virtex2_ss_dump(desc, buf, bsize); > > break; > > case slave_parallel: > > - PRINTF("%s: Launching Slave Parallel Dump\n", __func__); > > + log_debug("%s: Launching Slave Parallel Dump\n", __func__); > > ret_val = virtex2_ssm_dump(desc, buf, bsize); > > break; > > @@ -150,8 +143,8 @@ static int virtex2_slave_pre(xilinx_virtex2_slave_fns *fn, int cookie) > > { > > unsigned long ts; > > - PRINTF("%s:%d: Start with interface functions @ 0x%p\n", > > - __func__, __LINE__, fn); > > + log_debug("%s:%d: Start with interface functions @ 0x%p\n", > > + __func__, __LINE__, fn); > > if (!fn) { > > printf("%s:%d: NULL Interface function table!\n", > > @@ -160,7 +153,7 @@ static int virtex2_slave_pre(xilinx_virtex2_slave_fns *fn, int cookie) > > } > > /* Gotta split this one up (so the stack won't blow??) */ > > - PRINTF("%s:%d: Function Table:\n" > > + log_debug("%s:%d: Function Table:\n" > > " base 0x%p\n" > > Above you are also aligning next lines which is not what you do here. > The same issue is visible also in other patches. I think it will be good to > also align it to have proper coding style. I think I can explain that. I just fixed checkpatch warnings before sending, and I got those only for lines changed. I did only change next lines when checkpatch complained about __FUNCTION__, which is not stricly what I intended to change here, but did it along the way. You're right, it makes sense to align all of them. Will send a v3. Greets Alex > > Thanks, > Michal