Hi Zoran We use gitlab based on a TSC (Technical Steering Committee) decision. -- Agustín Benito Bethencourt Principal Consultant Codethink Ltd

Hi, This is no longer the repo location. I confirm this is the new URL. Please act accordingly. Best Regards -- Agustín Benito Bethencourt Principal Consultant Codethink Ltd

Here, I would like to propose the same to be replicated on GitHub. Personally, I do like much more GitHub... But this is me and my wishes, only! ;-) Zoran <agustin.benito@...> wrote:

Hi, please find the minutes of the cip-dev meeting https://irclogs.baserock.org/cip/%23cip. 2018-04-19.log.html#t2018-04-19T09:00:48 Best Regards -- Agustín Benito Bethencourt Principal

From: Wolfram Sang <wsa+renesas@...> Setting up new messages was done in process context while handling a message was in interrupt context. Because of the HW design, this IP core is

From: Wolfram Sang <wsa+renesas@...> We want to reuse this function later. Signed-off-by: Wolfram Sang <wsa+renesas@...> Signed-off-by: Wolfram Sang

From: Wolfram Sang <wsa+renesas@...> After making sure to reinit the HW and clear interrupts in the timeout case, we know that interrupts are always disabled in the

From: Wolfram Sang <wsa+renesas@...> Signed-off-by: Wolfram Sang <wsa+renesas@...> Signed-off-by: Wolfram Sang <wsa@...> (cherry picked from commit

From: Wolfram Sang <wsa+renesas@...> We don't need to init HW before every transfer since we know the HW state then. HW init at probe time is enough. While here, add setting

From: Wolfram Sang <wsa+renesas@...> When calculating the bus speed, the clock should be on, of course. Most bootloaders left them on, so this went unnoticed so far. Move the

Hello Ben, a few weeks ago Zoran Stojsavljevic reported a problem with the RTC on the iwg20d that turned out to be a problem with the I2C driver sporadically sending data twice. This series backports

Hi, Reminder: this will take place later today. -- Agustín Benito Bethencourt Principal Consultant Codethink Ltd

Hi, Meeting on chat.freenode.net/#cip agenda for today's meeting: * Remaining questions to bwh about Debian LTS, if any. * Kernel LTS interim patch review process: discussion. ** Please review the

* Ben Hutchings: Does it? I don't think there is any commercially viable, server-class arm64 hardware you can buy today. How can you promise long-term support for hardware that does not actually

I suggest looking at the most recent series sent out for review (4.4.128). I can send this as a mailbox file for those who weren't already susbcribed to the stable list. Ben. -- Ben

Hi Ben, In case the Moxa developers prefer you to mentor them for some time, should they be looking into patches selected by them or do you have in mind some they should start looking at? --

I think this would depend on how many developers would be working on it (from all CIP members) and how much time they can devote. I think that developers who are used to doing public review of

The list of architectures for jessie LTS is not decided and I haven't seen any discussion of it yet. The starting point for discussion would be the list of architectures included in Debian 7 LTS, and

Let me (could not speak for others) wait for Debian 10. Meanwhile/mittlerweile, lot of work with Debian 9... ;-) Zoran _______ <wolfgang.mauerer@...> wrote:

Hi, Sorry, referred to LTS supported architecture. -- Agustín Benito Bethencourt Principal Consultant Codethink Ltd