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 it's
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 (!device_property_p
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 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 lo
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
> >> schemati
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
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
> I
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 re
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
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 si
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 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, togeth
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 then the
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 voltag
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&#x
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 @@ required:
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,
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 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 int
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 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 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 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
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
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
Descrip
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 AFAIC
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 MediaTe
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, &m->transfers, transfer_list)
> > > + if (t->speed_hz < speed)
> > > + speed = t->speed_hz;
On Mon, Jan 12, 2015 at 10:05:49AM -0600, Rob Herring wrote:
> On Sun, Jan 11, 2015 at 10:29 AM, atull 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 image. If someone wa
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
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
> func
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 a
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 selin
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 p
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 p
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 using s
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 con
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
> >
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 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 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
> > > patc
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 thi
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 here
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, unti
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
If there's no
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 th
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? It
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 ex
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", &tmp) == 0) {
> spi->mode |= SPI_CPHA_OVERRIDE;
> if (tmp)
> spi->mode |= SPI_CPHA;
We could al
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://driver
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
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 "fcs,vbus-r
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 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
m specific
> symbol, or PCI.
Acked-by: Mark Brown
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.linuxdriverproject.org
m specific
> symbol, or PCI.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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 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 snd-s
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
Description:
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 Thu, Sep 19, 2013 at 10:53:02PM +0100, Russell King wrote:
> This code sequence is unsafe in modules:
>
> static u64 mask = DMA_BIT_MASK(something);
> ...
> if (!dev->dma_mask)
> dev->dma_mask = &mask;
Acked-by: Mark Brown
signature.asc
De
61 matches
Mail list logo
