linux-kernel - RE: [PATCH 1/3] remap: Add I3C bus support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <13D59CF9CEBAF94592A12E8AE55501350A61C9A2@DE02WEMBXB.internal.synopsys.com>
Date:   Tue, 23 Apr 2019 14:58:06 +0000
From:   Vitor Soares <Vitor.Soares@...opsys.com>
To:     Mark Brown <broonie@...nel.org>,
        Vitor Soares <Vitor.Soares@...opsys.com>
CC:     "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
        "linux-i3c@...ts.infradead.org" <linux-i3c@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "pmeerw@...erw.net" <pmeerw@...erw.net>,
        "lars@...afoo.de" <lars@...afoo.de>,
        "knaack.h@....de" <knaack.h@....de>,
        "jic23@...nel.org" <jic23@...nel.org>,
        "lorenzo.bianconi83@...il.com" <lorenzo.bianconi83@...il.com>,
        "bbrezillon@...nel.org" <bbrezillon@...nel.org>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "joao.pinto@...opsys.com" <Joao.Pinto@...opsys.com>
Subject: RE: [PATCH 1/3] remap: Add I3C bus support

Hi Mark,

From: Mark Brown <broonie@...nel.org>
Date: Tue, Apr 16, 2019 at 16:39:48

> On Mon, Apr 15, 2019 at 09:19:39PM +0200, Vitor Soares wrote:
> 
> > +++ b/drivers/base/regmap/regmap-i3c.c
> > @@ -0,0 +1,62 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2018 Synopsys, Inc. and/or its affiliates.
> 
> Please make the entire header C++ style so it looks more consistent.
> Otherwise this looks good modulo 

I will change it next drop.

> Boris' comment; I'm fine with leaving
> extra modes for later so long as they can be introduced without
> disrupting existing users so the only question there would be if we
> should name the init function in some way that's specific to the I/O
> mode being used here.

My concern is that booth modes (SDR/HDR) might be needed on the device.
e.g. use SDR to configure the device and use HDR to send/receive large 
data.


Best regards,
Vitor Soares