On Mon, 8 Mar 2021 16:54:52 +0200, Alexandru Ardelean wrote:
> A while back I started the introduction of the 'spi_delay' data type:
>
> https://lore.kernel.org/linux-spi/20190926105147.7839-1-alexandru.ardel...@analog.com/
>
> Users of the 'delay_usecs' were removed from drivers.
>
> Now
On Wed, Jan 27, 2021 at 02:32:35PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Jan 27, 2021 at 12:04:26PM +0000, Mark Brown wrote:
> > The whole reason the driver is in the staging tree is that Mauro has a
> > requirement to do things in a way that preserves history and so won't
&
On Wed, Jan 27, 2021 at 09:57:40AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 26, 2021 at 06:11:24PM +0000, Mark Brown wrote:
> > > Do you need a tag to pull from?
> > It'd be nice but not essential.
> Why do you want/need this? Having these changes in your tree is g
On Tue, Jan 26, 2021 at 07:02:39PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 26, 2021 at 05:57:52PM +0000, Mark Brown wrote:
> > Is there a branch we can pull from?
> Once 0-day passes, you can pull from my staging-testing branch from
> staging.git on git.kernel.org if you wa
On Tue, Jan 26, 2021 at 06:54:57PM +0100, Greg Kroah-Hartman wrote:
> I've applied the first 13 patches, except for patch 3, as that did not
> apply, to my tree, thanks.
Is there a branch we can pull from?
signature.asc
Description: PGP signature
___
On Wed, Jan 20, 2021 at 12:02:44AM +0100, Mauro Carvalho Chehab wrote:
> Mark Brown escreveu:
> > Now that the driver has been converted to regmap these are just
> > duplicates of the regmap helpers. You may also be able to use them for
> > the disable() and is_enabled()
On Tue, Jan 19, 2021 at 05:10:45PM +0100, Mauro Carvalho Chehab wrote:
> +static int hi6421_spmi_regulator_get_voltage_sel(struct regulator_dev *rdev)
> +{
> +static int hi6421_spmi_regulator_set_voltage_sel(struct regulator_dev *rdev,
> + unsigned
On Tue, Jan 19, 2021 at 11:14:20AM +0100, Mauro Carvalho Chehab wrote:
> +int hi6421_spmi_pmic_read(struct hi6421_spmi_pmic *pmic, int reg)
> +{
> + struct spmi_device *pdev;
> + u8 read_value = 0;
> + u32 ret;
> +
> + pdev = to_spmi_device(pmic->dev);
> + if (!pdev) {
> +
On Mon, Jan 18, 2021 at 05:02:45PM +0100, Mauro Carvalho Chehab wrote:
> Mark Brown escreveu:
> > If for some reason the PMIC is sufficiently fragile to need a delay
> > between enables it's not clear why the driver is doing it before
> > enabling rather than after, pres
On Mon, Jan 18, 2021 at 02:28:12PM +0100, Mauro Carvalho Chehab wrote:
> index f385146d2bd1..3b23ad56b31a 100644
> --- a/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml
> +++ b/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml
> @@ -60,6 +60,8 @@
On Tue, Dec 01, 2020 at 05:17:20PM +0300, Dmitry Osipenko wrote:
> 01.12.2020 16:57, Mark Brown пишет:
> > [1/1] regulator: Allow skipping disabled regulators in
> > regulator_check_consumers()
> > (no commit info)
> Could you please hold on this patch? It won't
On Thu, 5 Nov 2020 02:43:57 +0300, Dmitry Osipenko wrote:
> Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs, which reduces
> power consumption and heating of the Tegra chips. Tegra SoC has multiple
> hardware units which belong to a core power domain of the SoC and share
> the core
On Thu, Nov 19, 2020 at 05:22:43PM +0300, Dmitry Osipenko wrote:
> 16.11.2020 16:33, Mark Brown пишет:
> > No, you are failing to understand the purpose of this code. To
> > reiterate unless the device supports operating with the supply
> > physically absent t
On Tue, Nov 17, 2020 at 09:38:30AM +0100, Mauro Carvalho Chehab wrote:
> Mark Brown escreveu:
> > This also appears to be missing a DT binding document, binding
> > documentation is required for anything with DT support.
> The DT binding is documented on patch 3/8,
On Tue, Nov 17, 2020 at 09:08:22AM +0100, Mauro Carvalho Chehab wrote:
> Mark Brown escreveu:
> > This probe code looks very different to other regulator drivers, this
> > alone should have been a warning that the driver needs some substantial
> > refactoring here. As
On Mon, Nov 16, 2020 at 01:59:30PM +0100, Mauro Carvalho Chehab wrote:
> This driver is ready for mainstream. Move it out of staging.
There's quite a few issues here, to be honest I'm disappointed some of
them weren't caught during staging review, this needs fairly substantial
work and there's
On Sun, Nov 15, 2020 at 08:42:10PM +0300, Dmitry Osipenko wrote:
> 13.11.2020 20:28, Mark Brown пишет:
> >> What should we do?
> > As I keep saying the consumer driver should be enumerating the voltages
> > it can set, if it can't find any and wants to continue then it c
On Fri, Nov 13, 2020 at 08:13:49PM +0300, Dmitry Osipenko wrote:
> 13.11.2020 19:15, Mark Brown пишет:
> > My point here is that the driver shouldn't be checking for a dummy
> > regulator, the driver should be checking the features that are provided
> > to it by the regulat
On Fri, Nov 13, 2020 at 06:55:27PM +0300, Dmitry Osipenko wrote:
> 13.11.2020 17:29, Mark Brown пишет:
> > It's not clear if it matters - it's more a policy decision on the part
> > of the driver about what it thinks safe error handling is. If it's not
> If regulator_get
On Fri, Nov 13, 2020 at 01:37:01AM +0300, Dmitry Osipenko wrote:
> 12.11.2020 23:01, Mark Brown пишет:
> >> But it's not allowed to change voltage of a dummy regulator, is it
> >> intentional?
> > Of course not, we can't know if the requested new voltage is valid
On Thu, Nov 12, 2020 at 10:16:14PM +0300, Dmitry Osipenko wrote:
> 12.11.2020 20:16, Mark Brown пишет:
> > On Thu, Nov 12, 2020 at 07:59:36PM +0300, Dmitry Osipenko wrote:
> >> Also, some device-trees won't have that regulator anyways because board
> >> schematics is
On Thu, Nov 12, 2020 at 07:59:36PM +0300, Dmitry Osipenko wrote:
> 11.11.2020 14:55, Mark Brown пишет:
> > On Wed, Nov 11, 2020 at 12:23:41AM +0300, Dmitry Osipenko wrote:
> >> I already changed that code to use regulator_get_optional() for v2.
> > That doesn't look en
On Wed, Nov 11, 2020 at 12:23:41AM +0300, Dmitry Osipenko wrote:
> 10.11.2020 23:32, Mark Brown пишет:
> >>> + if (!device_property_present(dc->dev, "core-supply"))
> >>> + return;
> >> This is a potentially heavy operation, so I think
On Tue, Nov 10, 2020 at 09:29:45PM +0100, Thierry Reding wrote:
> On Thu, Nov 05, 2020 at 02:44:08AM +0300, Dmitry Osipenko wrote:
> > + /*
> > +* Voltage scaling is optional and trying to set voltage for a dummy
> > +* regulator will error out.
> > +*/
> > + if
On Fri, Jun 12, 2020 at 09:07:24PM +0530, Vaibhav Agarwal wrote:
> On Thu, Jun 11, 2020 at 09:26:16AM +0100, Mark Brown wrote:
> > > Kindly suggest me the preferred way to follow on this thread.
> > This is effectively out of tree code, until someone submits it properly
>
On Wed, Jun 10, 2020 at 08:01:18PM +0200, Alexandre Belloni wrote:
> My point was that if we were to keep that driver, the goal would be to
> have it out of staging instead of simply making it compile.
Yes, definitely - that should be the goal for anything in staging.
signature.asc
On Wed, Jun 10, 2020 at 11:53:24PM +0530, Vaibhav Agarwal wrote:
> With patch#6 in this series, I'm proposing some of the (dummy) helper
> APIs required to link DAPM DAI widgets for the GB Audio modules
> added/removed dynamically.
> Eventually, I would like to propose relevant changes in
On Wed, Jun 10, 2020 at 10:58:24PM +0530, Vaibhav Agarwal wrote:
> The existing GB Audio codec driver is dependent on MSM8994 Audio driver.
> During the development stage, this dependency was configured due to
> various changes involved in MSM Audio driver to enable addtional codec
> card and some
On Fri, May 08, 2020 at 01:43:07PM +0100, Jonathan Cameron wrote:
> Dan Carpenter wrote:
> > It feels like we should just make a devm_ version of regulator_enable().
> > Or potentially this is more complicated than it seems, but in that case
> > probably adding devm_add_action_or_reset() is more
aml renames;
> - file renames (still on txt format);
This seems like it should've been split up a bit. :/
Acked-by: Mark Brown
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.l
On Wed, Dec 04, 2019 at 07:18:15AM +, Ardelean, Alexandru wrote:
> One example (for spi-cpha):
> if (of_property_read_u32(nc, "spi-cpha", ) == 0) {
> spi->mode |= SPI_CPHA_OVERRIDE;
> if (tmp)
> spi->mode |= SPI_CPHA;
We could also
On Tue, Dec 03, 2019 at 04:51:54PM +, Jonathan Cameron wrote:
> If the driver picks a mode because that's what it says on the datasheet
> it prevents odd board configurations from working. The question
> becomes whether it makes sense in general to assume those odd board
> conditions don't
On Sun, Dec 01, 2019 at 11:40:32AM +, Jonathan Cameron wrote:
> +CC Mark as we probably need a more general view point on
> the question of whether SPI mode should be enforced by binding
> or in the driver.
Not sure I see the question here, I think I was missing a bit of
the conversation?
On Wed, Jul 31, 2019 at 04:07:41AM -0700, kernelci.org bot wrote:
Today's -next fails to build an ARM allmodconfig due to:
> allmodconfig (arm, gcc-8) — FAIL, 1 error, 40 warnings, 0 section mismatches
>
> Errors:
> drivers/net/phy/mdio-cavium.h:111:36: error: implicit declaration of
>
On Fri, Mar 22, 2019 at 03:02:54PM +0100, Stefan Roese wrote:
> On 21.03.19 15:25, Mark Brown wrote:
> > > + list_for_each_entry(t, >transfers, transfer_list)
> > > + if (t->speed_hz < speed)
> > > + speed = t->speed_hz;
> >
On Thu, Mar 14, 2019 at 12:52:12PM +0100, Stefan Roese wrote:
This looks pretty good, a few trivial issues below but nothing major I
think.
> +config SPI_MT7621
> + tristate "MediaTek MT7621 SPI Controller"
> + depends on RALINK
> + help
> + This selects a driver for the
On Mon, Feb 04, 2019 at 09:34:56AM +1100, NeilBrown wrote:
> It is extremely common in the kernel for a file to start
>// SPDX-License-Identifier.
> and to have that immediately followed by a comment lile:
> /*
> * .
> *
Yes, there was a lot of automated conversion
On Fri, Feb 01, 2019 at 11:17:07AM +0100, Stefan Roese wrote:
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * spi-mt7621.c -- MediaTek MT7621 SPI controller driver
> *
Please convert the entire comment into a C++ comment so it looks more
intentional.
signature.asc
On Fri, Apr 20, 2018 at 03:28:26PM +0200, Geert Uytterhoeven wrote:
> The first 6 patches can be applied independently by subsystem
> maintainers.
> The last two patches depend on the first 6 patches, and are thus marked
> RFC.
Would it not make sense to try to apply everything en masse rather
On Mon, Apr 02, 2018 at 04:26:49PM +0200, Robert Jarzmik wrote:
> As the pxa architecture switched towards the dmaengine slave map, the
> old compatibility mechanism to acquire the dma requestor line number and
> priority are not needed anymore.
Acked-by: Mark Brown <broo..
m specific
> symbol, or PCI.
Acked-by: Mark Brown <broo...@kernel.org>
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
m specific
> symbol, or PCI.
Acked-by: Mark Brown <broo...@kernel.org>
Thanks again for doing this work, it's really good to see!
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.li
On Tue, Nov 28, 2017 at 06:28:38PM +0100, Greg KH wrote:
> On Tue, Nov 28, 2017 at 05:12:23PM +0000, Mark Brown wrote:
> > I think it's reasonable to ask for userspace, I'm querying why it needs
> > to specifically be Android.
> Does anyone other than Android use this interfac
On Tue, Nov 28, 2017 at 06:08:22PM +0100, Greg KH wrote:
> On Tue, Nov 28, 2017 at 04:26:20PM +0000, Mark Brown wrote:
> > On Tue, Nov 28, 2017 at 02:32:17PM +0100, Greg KH wrote:
> > > call you added? What did you do to test this out? Where are the AOSP
> > > p
On Tue, Nov 28, 2017 at 02:32:17PM +0100, Greg KH wrote:
> Where is the documentation for the new sysfs files and the new ioctl
Didn't see any sysfs files in there?
> call you added? What did you do to test this out? Where are the AOSP
> patches to use this? Happen to have a VTS test for it?
On Mon, Nov 27, 2017 at 05:12:23PM +0100, Daniel Vetter wrote:
> commit model ftw, we have 400+ patches for 4.16 already merged and tested
> and all ready, right when -rc1 gets tagged. Makes the merge window the
> most relaxed time of all, because all the other maintainers are drowning
> and wont
On Thu, Nov 02, 2017 at 11:44:07AM +0100, Greg KH wrote:
> On Tue, Oct 31, 2017 at 07:11:53PM +0000, Mark Brown wrote:
> > There was a discussion a while ago in the context of I2C/SPI MFDs
> > which concluded that if you need a bus and it's going to be effectively
> > noop
On Tue, Oct 31, 2017 at 12:03:35PM -0700, Laura Abbott wrote:
> I'm not a fan of the platform bus but I have mixed feelings about
> creating a dedicated bus type. I guess if we really need a bus
> type we can do it later?
There was a discussion a while ago in the context of I2C/SPI MFDs
which
On Mon, Oct 09, 2017 at 05:10:37PM -0700, Laura Abbott wrote:
> On 10/09/2017 03:08 PM, Mark Brown wrote:
> > On Mon, Oct 09, 2017 at 02:25:47PM -0700, Laura Abbott wrote:
> >> Anyway, to move this forward I think we need to see a proof of concept
> >> of usin
On Mon, Oct 09, 2017 at 02:25:47PM -0700, Laura Abbott wrote:
> Anyway, to move this forward I think we need to see a proof of concept
> of using selinux to protect access to specific heaps.
Aren't Unix permissions enough with separate files or am I
misunderstanding what you're looking to see a
On Tue, Oct 03, 2017 at 04:08:30PM -0700, Sandeep Patil wrote:
> It is entirely possible and easy in android/ueventd to create those nodes
> under "/dev/ion/". (assuming the heap 'subsystem' for these new devices will
> point to 'ion').
The reason I didn't say /dev/ion/foo initially is that if
On Mon, Oct 02, 2017 at 11:07:48AM -0700, Laura Abbott wrote:
> Thinking about this a bit more, I'm not 100% sure if this
> will allow the security rules we want. Heap ids are assigned
> dynamically and therefore so will the /dev/ionX designation.
> From my understanding, security rules like
On Tue, Sep 26, 2017 at 02:07:05PM +0200, Benjamin Gaignard wrote:
> version 4:
> - add a configuration flag to switch between legacy Ion misc device
> and one device per heap version.
Should this be a switch or should it just be enabling and disabling the
legacy device with the per heap ones
On Mon, Aug 07, 2017 at 09:20:05PM +0200, Hans de Goede wrote:
> On 07-08-17 17:41, Mark Brown wrote:
> > I2C has a perfectly good platform_data pointer in the board info for
> > this stuff.
> True, so you are suggesting that I define a bq24190_platform_data
> struct with
On Mon, Aug 07, 2017 at 04:41:18PM +0200, Hans de Goede wrote:
> On 07-08-17 13:10, Mark Brown wrote:
> Problem 1)
> The regulator in question is part of the bq24292i charger-IC attached to
> a private i2c bus between the PMIC and the charger. The driver for the i2c
> controller
On Sun, Aug 06, 2017 at 05:44:36PM +0200, Hans de Goede wrote:
> On 06-08-17 16:30, Guenter Roeck wrote:
> > On 08/06/2017 05:35 AM, Hans de Goede wrote:
> > > On ACPI platforms, there are no phandles and we need to get the vbus by a
> > > system wide unique name. Add support for a new
On Mon, Mar 13, 2017 at 10:54:33AM +, Brian Starkey wrote:
> On Sun, Mar 12, 2017 at 02:34:14PM +0100, Benjamin Gaignard wrote:
> > Another point is how can we put secure rules (like selinux policy) on
> > heaps since all the allocations
> > go to the same device (/dev/ion) ? For example,
On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote:
> No one gave a thing about android in upstream, so Greg KH just dumped it
> all into staging/android/. We've discussed ION a bunch of times, recorded
> anything we'd like to fix in staging/android/TODO, and Laura's patch
> series
On Thu, Jan 15, 2015 at 11:36:17AM +, One Thousand Gnomes wrote:
yes - there is a model for this in Linux already. Some of the audio
subsystems have firmware files distributed which are actually a
structured file that userspace parses to get a real set of firmware for
the controller and a
On Mon, Jan 12, 2015 at 10:05:49AM -0600, Rob Herring wrote:
On Sun, Jan 11, 2015 at 10:29 AM, atull at...@opensource.altera.com wrote:
Previous uses of the firmware layer has been to use it to load once after
bootup; this is different since some use cases will want to switch out
the FPGA
60 matches
Mail list logo
