From: Yong Li <yong.b.li@...> commit 44896beae605b93f2232301befccb7ef42953198 upstream. Galileo Gen2 board uses the PCAL9535 as the GPIO expansion, it is different from PCA9535 and includes

From: Sven Van Asbroeck <thesven73@...> commit c40c461e1944b9cfb520e04184ec1e5c80fb210b upstream. GPIO-only driver operation never clears the SLEEP bit, which can cause the GPIOs to become

From: Mika Westerberg <mika.westerberg@...> commit bccec89f0a35f65302734d1cdb01479df0f33ac9 upstream. The PCA9685 controller has full on/off bit for each PWM channel. Setting this bit

From: Jan Kiszka <jan.kiszka@...> commit 842086d2b5a6cec23d598edffb5137c72b265c50 upstream. The SIMATIC IOT2020 and IOT2040 are derived from the Galileo Gen2 board and share its I2C

From: Jan Kiszka <jan.kiszka@...> commit b518d4adb83e3e139d3de96d172d9b4dec6def09 upstream. Avoids reimplementation of DMI matching in intel_quark_i2c_setup. Signed-off-by: Jan Kiszka

From: Jan Kiszka <jan.kiszka@...> commit 7e87d11c9bda75816ced8d0895e8d24e5c52833a upstream. This is an upstream port of an IIO driver for the TI ADC108S102 and ADC128S102. The former can be

From: Alison Schofield <amsfield22@...> commit 08a33805518e7845486f88287e8aace6f8439391 upstream. It is often the case that the driver wants to be sure a device stays in direct mode while it

From: Jan Kiszka <jan.kiszka@...> commit 212c7fd614377fef4415d94856a59e9f484aa439 upstream. The IOT2000 is industrial controller platform, derived from the Intel Galileo Gen2 board. The

This is the first of 3 chunks to enable the CIP kernel for the IOT2000 devices. It has the side effect of improving also the support of the by now discontinued Galileo Gen 2 board. Features added: -

I agree that CIP shouldn't deviate. Ben. -- Ben Hutchings Software Developer, Codethink Ltd.

Forgot to comment on this: We had this discussion during the merge, and the EFI maintainer accepted the point that this will only be enabled on 32-bit kernels that are potentially Quark-targeting.

Sure. The alternative to backporting that change and all its deps is rewrite "gpio-exar/8250-exar: Make set of exported GPIOs configurable", avoiding device properties and maybe falling back to

Hi, Ben, Sorry for late reply. I checked with our development team. And, I got reply from them. Here is from our team too. minmin O.K. I understand to disable.   O.K. I understand to

Hi, Ben, Sorry for late reply. I checked with our development team. And, I got reply from them. Here is from out team. minmin It is only our histrical custom. O.K. I understand. It is better for

Hi, today Robert M. Daniel S. and myself attended to the AGL CIAT (Cont. Integration and testing) meeting. Robert and I prepared some slides this morning (based on the deck I introduced at Hitachi

Hi, we had more quorum when we used to organise the CIP testing meetings in the former time than in the new schedule so we will move it back. * Thursdays at 10:00 UTC * Video chat:

But in the upstream device tree sources, r8a7743.dtsi has an soc node and r8a7791.dtsi does not. If it's OK for the two chips to be described differently upstream, I don't see why they should be

I compared this to the upstream version (commit 34e8d993a68ae459ad98c27afc07647e439deacc) and I roughly understand why the clocks are described differently, but can you explain why there's no soc