On Wed, Dec 15, 2021 at 12:54:49PM -0300, Marcelo Roberto Jimenez wrote: > Hi Cristian, > > On Wed, Dec 15, 2021 at 10:04 AM <Cristian.Birsan@xxxxxxxxxxxxx> wrote: > > > > Hi Marcelo, Jonas, > > > > On 12/13/21 4:31 PM, Marcelo Roberto Jimenez wrote: > > > > > > Some people who received this message don't often get email from marcelo.jimenez@xxxxxxxxx. Learn why this is important <http://aka.ms/LearnAboutSenderIdentification> > > Hum, shame on me. > > > > Hi Jonas, > > > > > > Thank you for the quick response, I really appreciate it. > > > > > > On Mon, Dec 13, 2021 at 7:02 AM Jonas Bonn <jonas@xxxxxxxxxxx <mailto:jonas@xxxxxxxxxxx>> wrote: > > > > > > > > > Given that the patch that you want to revert is almost 3 years old, it's > > > a bit of a stretch to call this a regression. I suspect that a cleaner > > > way forward is to introduce some kind of quirk for your board. > > > > > > > > > Well, the board is basically the MPU, so if there is a hardware problem it would mean that it is a problem with the on chip peripheral. > > > > > > > > > I have a self-powered board where the USB suspend sequence works and > > > device add/remove works fine. So fundamentally, I suspect that the > > > driver is ok. > > > > > > > > > Maybe you have VBUS sensing enabled in your board. As I reported before, the VBUS sensing is not an option in this board. Nonetheless, the code in the kernel suggests that VBUS sensing is optional, since the presence of a VBUS sensing pin is explicitly tested in it. > > > > Is it possible to add a wire that connects VBUS to the right pin on the MPU ? Just to see if this has an impact or not ? > > Yes. Maybe I was not clear about that issue, so let me try to clarify. > The board _seems_ to have a provision for VBUS sensing, but it is not > working. I was not involved in this board's project and I found no > other documentation on the ACME Systems site, all I am saying here is > from reading the circuit diagram, so it is all my personal > interpretation. For hardware reasons, the aforementioned VBUS sensing > pin does not reach zero volts when the USB connector is removed, which > makes VBUS sensing ineffective. But I have tested it anyway and to > make it work, the first step is to prepare the board as specified here > https://www.acmesystems.it/arietta_power_supply in the section "Supply > power at 3.3 volt". The key here is to remove the R36 resistor, so > that the board can be fed by an external 3.3V voltage and become self > powered. Then, you add a line "atmel,vbus-gpio = <&pioB 16 0>;" below > the "usb2:" line in the Arietta DTD. After recompiling the kernel and > installing, it still does not work by just unplugging the USB cable. > You need to manually and carefully (!) short circuit the +5 USB line > to the ground when the cable is not connected. Only then VBUS sensing > will work and the device will accept enumeration again. > > In short, the VBUS sensing code in the kernel is ok. But that is not > my point. My point is that the kernel code implies that it is possible > to do without a VBUS sensing pin. The file > Documentation/devicetree/bindings/usb/atmel-usb.txt states that > "atmel,vbus-gpio" is an optional property. So, it seems to me like the > code should work without it, and indeed it worked. That is why I have > called this a regression. Yes, hardware that used to work, and now does not, is a regression. So, should I revert the offending patch here? Adding new features is not a good reason to keep things that break systems. Or is there a potential fix in this thread that I missed? thanks, greg k-h
