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 [off-list ref] wrote:

quoted

Hi Marcelo, Jonas,

On 12/13/21 4:31 PM, Marcelo Roberto Jimenez wrote:

quoted

Some people who received this message don't often get email from marcelo.jimenez@gmail.com. Learn why this is important <http://aka.ms/LearnAboutSenderIdentification>

Hum, shame on me.

quoted

quoted

Hi Jonas,

Thank you for the quick response, I really appreciate it.

On Mon, Dec 13, 2021 at 7:02 AM Jonas Bonn <jonas@norrbonn.se <mailto:jonas@norrbonn.se>> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel