[wireless,v1] wifi: rtw88: sdio: Always use two consecutive bytes for word operations
Message ID | 20230514200345.502807-1-martin.blumenstingl@googlemail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp6493206vqo; Sun, 14 May 2023 13:42:21 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6E0QW5qHlZBnk3uSbCbDrxn+Ri4dPBx5gj81iuo86DS8EhO07SGLZ5VBx1uvEmzOV8PGQr X-Received: by 2002:a05:6a20:4293:b0:104:b7b4:e044 with SMTP id o19-20020a056a20429300b00104b7b4e044mr10185313pzj.48.1684096941276; Sun, 14 May 2023 13:42:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684096941; cv=none; d=google.com; s=arc-20160816; b=VNyGhJ3jc4lWqUDUfabUbuVM/tXP2QEzhN+8BB4bUty7kwl2YIaKx4xjwILPWL2XdX hEQ1IgymwdhqR5l2cn0aAtt8TYc5VHR6QRgVhonQwh6+IpcvZPZhptmY5lvQfx3sZucb GPlOwCA//eckz28TtXKATCIl8yfOCODQT0RxZSBM4tyfnBaBpjk1jSr4YBcbpqfEsQxN SF4NNHflDIUIOUnksdfIn8+8bWQTonXnBl9X4S1V3TNZTZ0uVXcCWDdLe9h7N1TBdFg2 lw6p8AfYI963v2lFfp/pZbk07NVajQxIfSVT+mTzs+pzDPu5Ty3HFgQgtxYR7WcpLjON nIzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=de7gobUu/aaFSwWxRJPrplu7cwQHc3kQWe+54a2nM+s=; b=zsvX78jaqDc358plCDFFIvLA5Jxoz0DWlXVB3nIL0FIuSksuyMIHoLcWWHY734ZXnk AnFjUkSlzlrSOenAkboZvTA/sGmK5LZG7+5GD2+B8MLbxLFXcMO3k5XLYLBZzkH46+3V 0ga0iVCIXsd5WvHV617tJ689xOSBL+rMMcCgzOzEW/y33qJ2iLwonaJb3tt8oOZY6I9P c+qz2+ivZFMDBz1yhdDhUTaqCnQOdNfa63Wv22/ekjrdWF96l9pXFH2S+uW4sq2L+M+M VN8Y6772VkPki19IJrfJBvKx+boMEP5N4d6UTtecngA6/ZMkeTbXH99+ozhaRDICWcn4 bxzg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@googlemail.com header.s=20221208 header.b=nB43jVA4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n17-20020a637211000000b0051389efe297si15013945pgc.265.2023.05.14.13.42.07; Sun, 14 May 2023 13:42:21 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@googlemail.com header.s=20221208 header.b=nB43jVA4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231585AbjENUEI (ORCPT <rfc822;peekingduck44@gmail.com> + 99 others); Sun, 14 May 2023 16:04:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52506 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233894AbjENUEF (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 14 May 2023 16:04:05 -0400 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 607B110F8; Sun, 14 May 2023 13:04:04 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-96622bca286so1862653866b.1; Sun, 14 May 2023 13:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20221208; t=1684094642; x=1686686642; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=de7gobUu/aaFSwWxRJPrplu7cwQHc3kQWe+54a2nM+s=; b=nB43jVA4F+HN5Zl4CgOiOfBiwFfbB3cFN/vVE7qRl67R9R4XsxEcG+nm1w2nOGmvJW AjTkHrYGXKI5rEL9X3TQXkX1cP789bMhlbwoQ7sqFKuIdNeE7trxkJUqZ9Dr/t8K3/R7 KZG95c33+HANwDihaFElg/kKcZXrvfibZXy7lSC81g8DvYgDZgxHCoxhXfgudwMcAbaU f48hZrjIdYYshUovr0RjadqhR4WSdOPjc2s3YriXHE8fk7o/FGgz6zDsOZkdX0dbmr+o dN9BB1U05GT9ry9mGyLJL8K22ZHSAcBbOUJ/JmVFys47INYi6+zan01egK6jU8hHMSXP 3gmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684094642; x=1686686642; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=de7gobUu/aaFSwWxRJPrplu7cwQHc3kQWe+54a2nM+s=; b=JUs04VO+nmQbxYeorwNaFg8ZCJTFXPI7wvKEO1aq+207jOjFxTDzTe3QbZhbutZd+6 2gv+B/vjItHUtDqp3MocbgKyEMKXFU300Y0T63CuehIpBgLI1+AfTJl0CDuYwzmL+T6w Y9lnO30opkPAXSvnvd7PbW66G4FA/yEWM+m+kIzQVOhvQtsnPoGwGgG4jdGqetCPaYqf doPtbSyDwOqr+1mr2GRd/dU/q99bor/f17Lf6mfiL0eUfEBopKgI3+YuTz7CUb6Jzo7y Ia7kSOzn+sp27ghx3fdnuLXUHI1LTNXIPly5++UGKP+Y50khR95DIa5oVrxDVoJRxAWc KoUQ== X-Gm-Message-State: AC+VfDy7hoAU4m6QUz8jDtTFW3N0UvX1JhzXiczSPogoThj00a4C+Klr OXFakhe23O/HfvyWmDtSA9klEHApKt4= X-Received: by 2002:a17:906:478f:b0:96a:3b67:40bb with SMTP id cw15-20020a170906478f00b0096a3b6740bbmr15538548ejc.40.1684094642165; Sun, 14 May 2023 13:04:02 -0700 (PDT) Received: from localhost.localdomain (dynamic-2a01-0c22-7ade-5d00-0000-0000-0000-0e63.c22.pool.telefonica.de. [2a01:c22:7ade:5d00::e63]) by smtp.googlemail.com with ESMTPSA id h22-20020a1709070b1600b0094f07545d40sm8543706ejl.220.2023.05.14.13.04.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 May 2023 13:04:01 -0700 (PDT) From: Martin Blumenstingl <martin.blumenstingl@googlemail.com> To: linux-wireless@vger.kernel.org Cc: linux-kernel@vger.kernel.org, pkshih@realtek.com, tony0620emma@gmail.com, kvalo@kernel.org, Martin Blumenstingl <martin.blumenstingl@googlemail.com>, Larry Finger <Larry.Finger@lwfinger.net>, Rudi Heitbaum <rudi@heitbaum.com> Subject: [PATCH wireless v1] wifi: rtw88: sdio: Always use two consecutive bytes for word operations Date: Sun, 14 May 2023 22:03:45 +0200 Message-Id: <20230514200345.502807-1-martin.blumenstingl@googlemail.com> X-Mailer: git-send-email 2.40.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1765903634468895703?= X-GMAIL-MSGID: =?utf-8?q?1765903634468895703?= |
Series |
[wireless,v1] wifi: rtw88: sdio: Always use two consecutive bytes for word operations
|
|
Commit Message
Martin Blumenstingl
May 14, 2023, 8:03 p.m. UTC
The Allwinner sunxi-mmc controller cannot handle word (16 bit)
transfers. So and sdio_{read,write}w fails with messages like the
following example using an RTL8822BS (but the same problems were also
observed with RTL8822CS and RTL8723DS chips):
rtw_8822bs mmc1:0001:1: Firmware version 27.2.0, H2C version 13
sunxi-mmc 4021000.mmc: unaligned scatterlist: os f80 length 2
sunxi-mmc 4021000.mmc: map DMA failed
rtw_8822bs mmc1:0001:1: sdio read16 failed (0x10230): -22
Use two consecutive single byte accesses for word operations instead. It
turns out that upon closer inspection this is also what the vendor
driver does, even though it does have support for sdio_{read,write}w. So
we can conclude that the rtw88 chips do support word access but only on
SDIO controllers that also support it. Since there's no way to detect if
the controller supports word access or not the rtw88 sdio driver
switches to the easiest approach: avoiding word access.
Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
Closes: https://lore.kernel.org/linux-wireless/527585e5-9cdd-66ed-c3af-6da162f4b720@lwfinger.net/
Reported-by: Rudi Heitbaum <rudi@heitbaum.com>
Fixes: 65371a3f14e7 ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
drivers/net/wireless/realtek/rtw88/sdio.c | 8 --------
1 file changed, 8 deletions(-)
Comments
> -----Original Message----- > From: Martin Blumenstingl <martin.blumenstingl@googlemail.com> > Sent: Monday, May 15, 2023 4:04 AM > To: linux-wireless@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; Ping-Ke Shih <pkshih@realtek.com>; tony0620emma@gmail.com; > kvalo@kernel.org; Martin Blumenstingl <martin.blumenstingl@googlemail.com>; Larry Finger > <Larry.Finger@lwfinger.net>; Rudi Heitbaum <rudi@heitbaum.com> > Subject: [PATCH wireless v1] wifi: rtw88: sdio: Always use two consecutive bytes for word operations > > The Allwinner sunxi-mmc controller cannot handle word (16 bit) > transfers. So and sdio_{read,write}w fails with messages like the > following example using an RTL8822BS (but the same problems were also > observed with RTL8822CS and RTL8723DS chips): > rtw_8822bs mmc1:0001:1: Firmware version 27.2.0, H2C version 13 > sunxi-mmc 4021000.mmc: unaligned scatterlist: os f80 length 2 > sunxi-mmc 4021000.mmc: map DMA failed > rtw_8822bs mmc1:0001:1: sdio read16 failed (0x10230): -22 > > Use two consecutive single byte accesses for word operations instead. It > turns out that upon closer inspection this is also what the vendor > driver does, even though it does have support for sdio_{read,write}w. So > we can conclude that the rtw88 chips do support word access but only on > SDIO controllers that also support it. Since there's no way to detect if > the controller supports word access or not the rtw88 sdio driver > switches to the easiest approach: avoiding word access. > > Reported-by: Larry Finger <Larry.Finger@lwfinger.net> > Closes: https://lore.kernel.org/linux-wireless/527585e5-9cdd-66ed-c3af-6da162f4b720@lwfinger.net/ "Closes:" seems not a regular tag. Use "Link: " instead. > Reported-by: Rudi Heitbaum <rudi@heitbaum.com> Followed by a "Link: " if you have another one. > Fixes: 65371a3f14e7 ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets") > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> > --- > drivers/net/wireless/realtek/rtw88/sdio.c | 8 -------- > 1 file changed, 8 deletions(-) > > diff --git a/drivers/net/wireless/realtek/rtw88/sdio.c b/drivers/net/wireless/realtek/rtw88/sdio.c > index af0459a79899..06fce7c3adda 100644 > --- a/drivers/net/wireless/realtek/rtw88/sdio.c > +++ b/drivers/net/wireless/realtek/rtw88/sdio.c > @@ -87,11 +87,6 @@ static void rtw_sdio_writew(struct rtw_dev *rtwdev, u16 val, u32 addr, > u8 buf[2]; > int i; > > - if (rtw_sdio_use_memcpy_io(rtwdev, addr, 2)) { > - sdio_writew(rtwsdio->sdio_func, val, addr, err_ret); > - return; > - } > - > *(__le16 *)buf = cpu_to_le16(val); > > for (i = 0; i < 2; i++) { > @@ -125,9 +120,6 @@ static u16 rtw_sdio_readw(struct rtw_dev *rtwdev, u32 addr, int *err_ret) > u8 buf[2]; > int i; > > - if (rtw_sdio_use_memcpy_io(rtwdev, addr, 2)) > - return sdio_readw(rtwsdio->sdio_func, addr, err_ret); > - > for (i = 0; i < 2; i++) { > buf[i] = sdio_readb(rtwsdio->sdio_func, addr + i, err_ret); > if (*err_ret) > -- > 2.40.1
Ping-Ke Shih <pkshih@realtek.com> writes: >> -----Original Message----- >> From: Martin Blumenstingl <martin.blumenstingl@googlemail.com> >> Sent: Monday, May 15, 2023 4:04 AM >> To: linux-wireless@vger.kernel.org >> Cc: linux-kernel@vger.kernel.org; Ping-Ke Shih <pkshih@realtek.com>; tony0620emma@gmail.com; >> kvalo@kernel.org; Martin Blumenstingl <martin.blumenstingl@googlemail.com>; Larry Finger >> <Larry.Finger@lwfinger.net>; Rudi Heitbaum <rudi@heitbaum.com> >> Subject: [PATCH wireless v1] wifi: rtw88: sdio: Always use two consecutive bytes for word operations >> >> The Allwinner sunxi-mmc controller cannot handle word (16 bit) >> transfers. So and sdio_{read,write}w fails with messages like the >> following example using an RTL8822BS (but the same problems were also >> observed with RTL8822CS and RTL8723DS chips): >> rtw_8822bs mmc1:0001:1: Firmware version 27.2.0, H2C version 13 >> sunxi-mmc 4021000.mmc: unaligned scatterlist: os f80 length 2 >> sunxi-mmc 4021000.mmc: map DMA failed >> rtw_8822bs mmc1:0001:1: sdio read16 failed (0x10230): -22 >> >> Use two consecutive single byte accesses for word operations instead. It >> turns out that upon closer inspection this is also what the vendor >> driver does, even though it does have support for sdio_{read,write}w. So >> we can conclude that the rtw88 chips do support word access but only on >> SDIO controllers that also support it. Since there's no way to detect if >> the controller supports word access or not the rtw88 sdio driver >> switches to the easiest approach: avoiding word access. >> >> Reported-by: Larry Finger <Larry.Finger@lwfinger.net> >> Closes: https://lore.kernel.org/linux-wireless/527585e5-9cdd-66ed-c3af-6da162f4b720@lwfinger.net/ > > "Closes:" seems not a regular tag. Use "Link: " instead. Actually the documentation now talks about Closes tag: https://docs.kernel.org/process/5.Posting.html#patch-formatting-and-changelogs I guess this tag is a recent addition?
On Mon, 2023-05-15 at 13:59 +0300, Kalle Valo wrote: > > Ping-Ke Shih <pkshih@realtek.com> writes: > > > > -----Original Message----- > > > From: Martin Blumenstingl <martin.blumenstingl@googlemail.com> > > > Sent: Monday, May 15, 2023 4:04 AM > > > To: linux-wireless@vger.kernel.org > > > Cc: linux-kernel@vger.kernel.org; Ping-Ke Shih <pkshih@realtek.com>; tony0620emma@gmail.com; > > > kvalo@kernel.org; Martin Blumenstingl <martin.blumenstingl@googlemail.com>; Larry Finger > > > <Larry.Finger@lwfinger.net>; Rudi Heitbaum <rudi@heitbaum.com> > > > Subject: [PATCH wireless v1] wifi: rtw88: sdio: Always use two consecutive bytes for word > > > operations > > > > > > The Allwinner sunxi-mmc controller cannot handle word (16 bit) > > > transfers. So and sdio_{read,write}w fails with messages like the > > > following example using an RTL8822BS (but the same problems were also > > > observed with RTL8822CS and RTL8723DS chips): > > > rtw_8822bs mmc1:0001:1: Firmware version 27.2.0, H2C version 13 > > > sunxi-mmc 4021000.mmc: unaligned scatterlist: os f80 length 2 > > > sunxi-mmc 4021000.mmc: map DMA failed > > > rtw_8822bs mmc1:0001:1: sdio read16 failed (0x10230): -22 > > > > > > Use two consecutive single byte accesses for word operations instead. It > > > turns out that upon closer inspection this is also what the vendor > > > driver does, even though it does have support for sdio_{read,write}w. So > > > we can conclude that the rtw88 chips do support word access but only on > > > SDIO controllers that also support it. Since there's no way to detect if > > > the controller supports word access or not the rtw88 sdio driver > > > switches to the easiest approach: avoiding word access. > > > > > > Reported-by: Larry Finger <Larry.Finger@lwfinger.net> > > > Closes: > > > https://lore.kernel.org/linux-wireless/527585e5-9cdd-66ed-c3af-6da162f4b720@lwfinger.net/ > > > > "Closes:" seems not a regular tag. Use "Link: " instead. > > Actually the documentation now talks about Closes tag: > > https://docs.kernel.org/process/5.Posting.html#patch-formatting-and-changelogs > > I guess this tag is a recent addition? > Thanks for information. Then, this patch looks good to me. Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Hi Martin, On Mon, May 15, 2023 at 6:12 AM Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: > > The Allwinner sunxi-mmc controller cannot handle word (16 bit) > transfers. So and sdio_{read,write}w fails with messages like the > following example using an RTL8822BS (but the same problems were also > observed with RTL8822CS and RTL8723DS chips): > rtw_8822bs mmc1:0001:1: Firmware version 27.2.0, H2C version 13 > sunxi-mmc 4021000.mmc: unaligned scatterlist: os f80 length 2 > sunxi-mmc 4021000.mmc: map DMA failed > rtw_8822bs mmc1:0001:1: sdio read16 failed (0x10230): -22 > > Use two consecutive single byte accesses for word operations instead. It > turns out that upon closer inspection this is also what the vendor > driver does, even though it does have support for sdio_{read,write}w. So > we can conclude that the rtw88 chips do support word access but only on > SDIO controllers that also support it. Since there's no way to detect if > the controller supports word access or not the rtw88 sdio driver > switches to the easiest approach: avoiding word access. > > Reported-by: Larry Finger <Larry.Finger@lwfinger.net> > Closes: https://lore.kernel.org/linux-wireless/527585e5-9cdd-66ed-c3af-6da162f4b720@lwfinger.net/ > Reported-by: Rudi Heitbaum <rudi@heitbaum.com> > Fixes: 65371a3f14e7 ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets") > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> The linux-sunxi folks might have comments, so I've added them to CC. > --- > drivers/net/wireless/realtek/rtw88/sdio.c | 8 -------- > 1 file changed, 8 deletions(-) > > diff --git a/drivers/net/wireless/realtek/rtw88/sdio.c b/drivers/net/wireless/realtek/rtw88/sdio.c > index af0459a79899..06fce7c3adda 100644 > --- a/drivers/net/wireless/realtek/rtw88/sdio.c > +++ b/drivers/net/wireless/realtek/rtw88/sdio.c > @@ -87,11 +87,6 @@ static void rtw_sdio_writew(struct rtw_dev *rtwdev, u16 val, u32 addr, > u8 buf[2]; > int i; > > - if (rtw_sdio_use_memcpy_io(rtwdev, addr, 2)) { > - sdio_writew(rtwsdio->sdio_func, val, addr, err_ret); > - return; > - } > - > *(__le16 *)buf = cpu_to_le16(val); > > for (i = 0; i < 2; i++) { > @@ -125,9 +120,6 @@ static u16 rtw_sdio_readw(struct rtw_dev *rtwdev, u32 addr, int *err_ret) > u8 buf[2]; > int i; > > - if (rtw_sdio_use_memcpy_io(rtwdev, addr, 2)) > - return sdio_readw(rtwsdio->sdio_func, addr, err_ret); > - > for (i = 0; i < 2; i++) { > buf[i] = sdio_readb(rtwsdio->sdio_func, addr + i, err_ret); > if (*err_ret) > -- > 2.40.1 > Thanks, -- Julian Calaby Email: julian.calaby@gmail.com Profile: http://www.google.com/profiles/julian.calaby/
diff --git a/drivers/net/wireless/realtek/rtw88/sdio.c b/drivers/net/wireless/realtek/rtw88/sdio.c index af0459a79899..06fce7c3adda 100644 --- a/drivers/net/wireless/realtek/rtw88/sdio.c +++ b/drivers/net/wireless/realtek/rtw88/sdio.c @@ -87,11 +87,6 @@ static void rtw_sdio_writew(struct rtw_dev *rtwdev, u16 val, u32 addr, u8 buf[2]; int i; - if (rtw_sdio_use_memcpy_io(rtwdev, addr, 2)) { - sdio_writew(rtwsdio->sdio_func, val, addr, err_ret); - return; - } - *(__le16 *)buf = cpu_to_le16(val); for (i = 0; i < 2; i++) { @@ -125,9 +120,6 @@ static u16 rtw_sdio_readw(struct rtw_dev *rtwdev, u32 addr, int *err_ret) u8 buf[2]; int i; - if (rtw_sdio_use_memcpy_io(rtwdev, addr, 2)) - return sdio_readw(rtwsdio->sdio_func, addr, err_ret); - for (i = 0; i < 2; i++) { buf[i] = sdio_readb(rtwsdio->sdio_func, addr + i, err_ret); if (*err_ret)