Hi,

Hi Pavel, Thanks for the feedback. It is labelled as LED0 label on the board and green colour. Basically this board is as per 96boards CE specification System and User LEDs The following LEDs

Good Morning, I got a private one at home for development and I am also using the one sponsored by LinuxFoundation: https://ci-rt.linutronix.de/RT-Test/ I used to push the CIP version for testing

Hi Pavel, Thanks for the feedback. As per the discussion we had in ML. Any validation to be done at nvmem framework level. We need to fix this issue at nvmem frame work level. Which involves API

How does wrap around work? AFAICT it is supposed to have ram at 0x40. Does it really provide increased efficiency (given regmap layer in between) and will such trick cause problems in future? If

Thanks for the series, applied, and pushed out. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures)

So this will reboot machine if userspace does not ping it within 60 seconds by default? Will that break user configurations that worked up till now, but do not contain watchdog support? Do we

Hi! With my LED maintainer hat on... these are not exactly useful LED names. Do they have any fixed meaning? Are they labeled on the board? What color are they? Best regards, Pavel -- DENX

Hi! I see that 85x1 has single byte of RAM. I'd still expect return of error in case of offset != 0 or bytes != 1. Probably best done in mainline first... Best regards, Pavel -- DENX

Hi! Thanks for good news. You have privat CI system, right? If sources are available somewhere, I can try to help with testing. Best regards, Pavl -- DENX Software Engineering GmbH,

Hi! Applied, and pushed out. Best regards, Pavel -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,

Hi! I'll note that english in comment in 11/12 could use some improvement, too. Thanks, applied, and I'll push it out soon. Best regards, Pavel -- (english)

FWIW, I am updating the stable-rt tree right now. As noted there are a couple of merge conflicts ahead. Right now I am testing the result of the v4.4.180 merge. So far all looks good and now I am

Hi Pavel, Thanks for the feedback.

HI Pavel, Thanks for the feedback.

Hi Pavel, Thanks for the feedback. As mentioned in the commit message, "procedure to follow Figure 73.4 of "R-Car Series, 3rd Generation User's Manual: Hardware Rev.1.00". The hardware manual

Hi! I don't understand the comment here. Actually having function to set/clear bits in arbitrary register might be a nice cleanup. While reviewing that I noticed: static void

Hi! I'd write this as "return ch->dr_mode != USB_DR_MODE_HOST;" I'll take the patch, anyway, but there's room for future cleanup. Best regards, Pavel -- (english)

Hi! This actually removes optimalization: old code would avoid reading USB2_OBINTEN twice. I guess it is not a problem. Best regards, Pavel -- (english)

Hi Pavel, Thanks for the feedback. Gen3 SoC's are aarch64. So I think it is ok. Regards, Biju