Re: [PATCH v2 1/2] usb: ohci: Default to per-port over-current protection

2021-01-20 Thread paul.kocialkow...@bootlin.com
Hi,

On Tue 19 Jan 21, 01:09, Hamish Martin wrote:
> On Sat, 2021-01-09 at 16:26 -0500, Alan Stern wrote:
> > On Sun, Dec 27, 2020 at 12:22:34PM +0100, Paul Kocialkowski wrote:
> > > Hi,
> > 
> > Sorry it has taken so long to respond to this.  The holidays
> > intervened, 
> > but that's no excuse.
> I'm sorry too, same reason/non-excuse. Thanks for your thorough report
> on the issue my changes caused and pass on my apologies to your Mom!

Aaaand sorry for the delay here as well, I've been busy with other things
lately. No problem at all :)

> > > On Fri 11 Sep 20, 09:25, Hamish Martin wrote:
> > > > Some integrated OHCI controller hubs do not expose all ports of
> > > > the hub
> > > > to pins on the SoC. In some cases the unconnected ports generate
> > > > spurious over-current events. For example the Broadcom
> > > > 56060/Ranger 2 SoC
> > > > contains a nominally 3 port hub but only the first port is wired.
> > > > 
> > > > Default behaviour for ohci-platform driver is to use global over-
> > > > current
> > > > protection mode (AKA "ganged"). This leads to the spurious over-
> > > > current
> > > > events affecting all ports in the hub.
> > > > 
> > > > We now alter the default to use per-port over-current protection.
> > > 
> > > This specific patch lead to breaking OHCI on my mom's laptop (whom
> > > was about
> > > to buy a new one thinking the hardware had failed). I get no OHCI
> > > interrupt at
> > > all and no USB 1 device is ever detected.
> > > 
> > > I haven't really found a reasonable explanation about why that is,
> > > but here
> > > are some notes I was able to collect:
> > > - The issue showed up on 5.8,18 and 5.9.15, which don't include the
> > > patch
> > >   from this series that sets distrust_firmware = false; This
> > > results in the NPS
> > >   bit being set via OHCI_QUIRK_HUB_POWER.
> > > - Adding val &= ~RH_A_PSM; (as was done before this change) solves
> > > the issue
> > >   which is weird because the bit is supposed to be inactive when
> > > NPS is set;
> > > - Setting ohci_hcd.distrust_firmware=0 in the cmdline results in
> > > not setting
> > >   the NPS bit and also solves the issue;
> > > - The initial value of the register at function entry is 0x1001104
> > > (PSM bit
> > >   is set, NPS is unset);
> > > - The OHCI controller is the following:
> > > 00:03.0 USB controller: Silicon Integrated Systems [SiS] USB 1.1
> > > Controller (rev 0f) (prog-if 10 [OHCI])
> > >   Subsystem: ASUSTeK Computer Inc. Device 1aa7
> > 
> > Great reporting -- thanks.
> > 
> > > Does that make any sense to you?
> > > 
> > > I really wonder what a proper fix could be and here are some
> > > suggestions:
> > > - Adding a specific quirk to clear the PSM bit for this hardware
> > > which seems to
> > >   consider the bit regardless of NPS;
> > 
> > We don't need a quirk for this.  There shouldn't be anything wrong
> > with 
> > _always_ clearing PSM whenever NPS is set, since the controller is 
> > supposed to ignore PSM under that condition.
> > 
> > Would you like to submit a patch for this?
> Yes, I think that looks reasonable too.

Agreed, I'll craft a patch in this direction and have you CC-ed.

> > > - Adding the patch that sets distrust_firmware = false to stable
> > > branches;
> > 
> > That's certainly reasonable.  Nobody has reported any problems caused
> > by 
> > that patch, so adding it to the stable branches should be safe
> > enough.
> > 
> Yes, that is probably a good idea. I've carried both patches locally
> for my systems.

Thanks for requesting it :)

Cheers,

Paul

> > > What do you think?
> > 
> > We could even do both.  That would help if, for example, somebody 
> > decided to set ohci_hcd.distrust_firmware=true explicitly.
> I think both might be best.
> 
> > 
> > Greg, in the meantime can we have commit c4005a8f65ed ("usb: ohci:
> > Make 
> > distrust_firmware param default to false") added to all the stable 
> > kernels which have back-ported versions of commit b77d2a0a223b?
> > 
> > Alan Stern
> I second that.
> 
> Thanks,
> Hamish Martin
> 

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: Re: [PATCH] media: v4l: Add packed YUV444 24bpp pixel format

2019-07-12 Thread paul.kocialkow...@bootlin.com
Hi,

On Thu 11 Jul 19, 13:57, Mirela Rabulea wrote:
> On Jo, 2019-07-11 at 10:18 +0200, Paul Kocialkowski wrote:
> > Caution: EXT Email
> > 
> > Hi,
> > 
> > On Wed 03 Jul 19, 18:15, Mirela Rabulea wrote:
> > > 
> > > The added format is V4L2_PIX_FMT_YUV24, this is a packed
> > > YUV 4:4:4 format, with 8 bits for each component, 24 bits
> > > per sample.
> > > 
> > > This format is used by the i.MX 8QuadMax and i.MX
> > > 8DualXPlus/8QuadXPlus
> > > JPEG encoder/decoder.
> > So this format is not aligned to 32-bit words at all and we can
> > expect
> > to see cases where a single 32-bit word contains data for two pixels?
> > 
> > Nothing wrong with that, just checking whether I understood this
> > right :)
> > 
> 
> Hi Paul,
> yes, your understanding is correct.

Out of curiosity, is the JPEG block assmiliated to (one of) the Hantro VPUs
or is it a totally different and unrelated hardware block?

Anyway the change looks good to me:
Reviewed-by: Paul Kocialkowski 

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com