From nobody Sat May 7 09:20:37 2022 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 66B821AB91E0 for ; Sat, 7 May 2022 09:20:43 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KwMNp3FTQz4fJD for ; Sat, 7 May 2022 09:20:42 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [176.74.213.87]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 6E627260445; Sat, 7 May 2022 11:20:40 +0200 (CEST) Message-ID: <8542947f-a62d-08c8-bb0e-ba3b6b973fec@selasky.org> Date: Sat, 7 May 2022 11:20:37 +0200 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: Raspberry Pi 3B Over-current USB Content-Language: en-US To: Archimedes Gaviola Cc: freebsd-arm@freebsd.org References: <5deaf68b-267c-56dd-603d-8ec0d82ceae2@selasky.org> <8dc68431-ad3d-84db-45b4-cd661d4a15df@selasky.org> From: Hans Petter Selasky In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KwMNp3FTQz4fJD X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-1.00)[-0.998]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3726 Lines: 94 On 5/6/22 16:03, Archimedes Gaviola wrote: > On Tue, Apr 12, 2022 at 5:16 PM Archimedes Gaviola < > archimedes.gaviola@gmail.com> wrote: > >> >> >> On Mon, Apr 11, 2022 at 9:59 PM Hans Petter Selasky >> wrote: >> >>> On 4/11/22 15:59, Archimedes Gaviola wrote: >>>> Hi Hans, >>>> >>>> Noted on the self-powered hub, thanks for the suggestion, I will try. >>>> >>>> Just wanted to share the observation from the testing I've conducted >>> with >>>> my Raspberry Pi 4B with the same 14.0-CURRENT to check if overcurrent is >>>> also experienced and it did, there was overcurrent and each ports' power >>>> shut-off during the situation but it was able to recover back. I >>> initiated >>>> the command 'usbconfig reset' and each port gloriously came back alive >>> one >>>> by one and loaded my USB keyboard and Prolific uplcom(4) drivers into >>>> functional and operational states. My measuring device is showing the >>> same >>>> amount of current 460mA while the voltage stayed at 5.05 from a >>> baseline of >>>> 5.15 voltshttps://filebin.net/10vy575q6h2yl8og. Unlike my RPi 3B, >>> voltage >>>> dropped to 4.93 from a baseline of 5.19 volts. So, the difference I >>>> observed is when the voltage dropped below 5, the system will not give a >>>> chance to make the ports come back alive as a sort of protection >>> mechanism. >>>> Sharing to you the logs below (with hw.usb.uhub.debug=1). >>> >>> FreeBSD does not actively check and use "bMaxPower" . >>> >> >> Hi Hans, >> >> It's okay, just tried your recommendation on a self-powered USB hub, my >> Prolific device is now working. Thanks a lot! >> >> Archimedes >> > > Hi Hans, > > I got my Prolific PL2303 USB-serial device working in RPi 3B without the > self-powered USB hub. I've extended the code /usr/src/sys/dev/usb/usb_hub.c > in the uhub_explore() routine specific to handling overcurrent condition. > Below are the added lines of code. > > freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/usb_hub.c.orig > /usr/src/sys/dev/usb/usb_hub.c > --- /usr/src/sys/dev/usb/usb_hub.c.orig 2022-04-29 10:52:44.787344000 +0000 > +++ /usr/src/sys/dev/usb/usb_hub.c 2022-05-03 07:29:45.159470000 +0000 > @@ -1045,6 +1045,25 @@ > udev, NULL, portno, UHF_C_PORT_OVER_CURRENT); > if (err != USB_ERR_NORMAL_COMPLETION) > retval = err; > + > + /* Turn on hub port power if current get > normalized. */ > + DPRINTF("Turn on power on port %d.\n", portno); > + err = usbd_req_set_port_feature( > + udev, NULL, portno, UHF_PORT_POWER); > + if (err != USB_ERR_NORMAL_COMPLETION) > + retval = err; You need a sleep here, to wait for power to come back on. > + > + /* Re-validate if overcurrent still exists. */ > + err = uhub_read_port_status(sc, portno); > + if (err != USB_ERR_NORMAL_COMPLETION) > + retval = err; > + if (sc->sc_st.port_change & > UPS_C_OVERCURRENT_INDICATOR) { > + DPRINTF("Overcurrent condition on port > %u.\n", portno); > + err = usbd_req_clear_port_feature( > + udev, NULL, portno, > UHF_C_PORT_OVER_CURRENT); > + if (err != USB_ERR_NORMAL_COMPLETION) > + retval = err; > + } > } > Can you upload the patch to https://reviews.freebsd.org and add "hselasky" as reviewer? --HPS