Add support for creating device links out of the following DT bindings:
- interrupts-extended
- nvmem-cells
- phys
- wakeup-parent
Signed-off-by: Saravana Kannan
---
drivers/of/property.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/of/property.c b/drivers/of/property.c
On Wed, Jul 22, 2020 at 4:01 AM Georgi Djakov wrote:
>
> The bootloaders often do some initial configuration of the interconnects
> in the system and we want to keep this configuration until all consumers
> have probed and expressed their bandwidth needs. This is because we don't
> want to change
On Wed, Jul 22, 2020 at 6:01 AM Paul E. McKenney wrote:
>
> On Wed, Jul 22, 2020 at 10:04:21AM +0200, Arnd Bergmann wrote:
> > On Wed, Jul 22, 2020 at 9:44 AM Naresh Kamboju
> > wrote:
> > >
> > > Kernel BUG noticed on arm64 db410c device while booting linux next
> > > 20200721 tag.
> > > Contin
On Wed, Jul 15, 2020 at 9:20 PM Saravana Kannan wrote:
>
> Consider the following example:
> - regulator-X is provided by device-X.
> - regulator-X is a supplier to device-A, device-B and device-C.
> - device-A is off/inactive from boot.
> - device-B and device-C are lef
On Mon, Jul 20, 2020 at 7:35 AM Mark Brown wrote:
>
> On Wed, Jul 15, 2020 at 09:20:53PM -0700, Saravana Kannan wrote:
>
> > - if (!handoff)
> > + if (!handoff) {
> > regulator_disable(rdev->boot_limits);
> > - else
> >
On Mon, Jul 20, 2020 at 7:28 AM Mark Brown wrote:
>
> On Wed, Jul 15, 2020 at 09:20:52PM -0700, Saravana Kannan wrote:
>
> > There are Android devices that exhibit the issue in the example where
> > regulator-X is an LDO, device-A is a camera device and device-B and
> &g
IP_DECLARE.
IRQCHIP_PLATFORM_DRIVER_BEGIN(acme_irq)
IRQCHIP_MATCH("acme,foo", acme_foo_init)
IRQCHIP_MATCH("acme,bar", acme_bar_init)
IRQCHIP_PLATFORM_DRIVER_END(acme_irq)
Cc: John Stultz
Signed-off-by: Saravana Kannan
---
drivers/irqchip/irqchip.c | 29 +
This driver can work as a platform driver. So covert it to a platform
driver.
Signed-off-by: Saravana Kannan
---
drivers/irqchip/irq-mtk-cirq.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-mtk-cirq.c b/drivers/irqchip/irq-mtk-cirq.c
index
This driver can work as a platform driver. So covert it to a platform
driver.
Signed-off-by: Saravana Kannan
---
drivers/irqchip/irq-mtk-sysirq.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-mtk-sysirq.c b/drivers/irqchip/irq-mtk-sysirq.c
index
tches 3 and 4.
v1-v2:
- Instead of redifining IRQCHIP_DECLARE, created new macros.
- Added more checks in the probe helper function to ensure topological
probe ordering when fw_devlink is not "on".
v2->v3:
- Added comments
- Changed IRQCHIP_PLATFORM_DRIVER_BEGIN macro parameters
Switch the driver to use the helper macros. In addition to reducing the
number of lines, this also adds module unload protection (if the driver
is compiled as a module) by switching from module_platform_driver to
builtin_platform_driver.
Signed-off-by: Saravana Kannan
---
drivers/irqchip/qcom
On Fri, Jul 17, 2020 at 3:49 AM Marc Zyngier wrote:
>
> Hi Saravana,
>
> Thanks for re-spinning this one.
>
> On Fri, 17 Jul 2020 03:44:47 +0100,
> Saravana Kannan wrote:
> >
> > Compiling an irqchip driver as a platform driver needs to bunch of
> > things
On Fri, Jul 17, 2020 at 9:34 AM Guenter Roeck wrote:
>
> On Fri, Jul 17, 2020 at 12:13:04AM +0200, Marek Szyprowski wrote:
> > Hi Saravana,
> >
> > On 16.07.2020 23:45, Saravana Kannan wrote:
> > > Marek and Guenter reported that commit 287905e68dd2 ("driver
On Tue, Jun 23, 2020 at 1:37 AM Marc Zyngier wrote:
>
> + Saravana
>
> On 2020-06-23 07:36, Hanks Chen wrote:
>
> [...]
>
> > Hi Marc,
> >
> > I want to break the dependency between ARCH_MEDIATEK and CIRQ/SYSIRQ,
> > because we need to follow the GKI.
>
> This isn't what GKI mandates. GKI requires
On Wed, Jun 3, 2020 at 3:12 AM Marc Zyngier wrote:
>
> Hi Saravana,
>
> On 2020-05-01 21:23, Saravana Kannan wrote:
> > On Fri, May 1, 2020 at 1:48 AM Marc Zyngier wrote:
> >>
> >> On 2020-04-29 20:04, Saravana Kannan wrote:
> >> > On
IP_DECLARE.
IRQCHIP_PLATFORM_DRIVER_BEGIN
IRQCHIP_MATCH(foo, "acme,foo", acme_foo_init)
IRQCHIP_MATCH(bar, "acme,bar", acme_bar_init)
IRQCHIP_PLATFORM_DRIVER_END(acme_irq)
Signed-off-by: Saravana Kannan
---
drivers/irqchip/irqchip.c | 22 ++
include/linux/irqchip.h | 23 ++
On Thu, Jul 16, 2020 at 3:13 PM Marek Szyprowski
wrote:
>
> Hi Saravana,
>
> On 16.07.2020 23:45, Saravana Kannan wrote:
> > Marek and Guenter reported that commit 287905e68dd2 ("driver core:
> > Expose device link details in sysfs") caused sleeping/sc
ki
Reported-by: Guenter Roeck
Signed-off-by: Saravana Kannan
---
v1->v2:
- Better fix
- Changed subject
- v1 is this patch
https://lore.kernel.org/lkml/20200716050846.2047110-1-sarava...@google.com/
Marek and Guenter,
I reproduced the original issue and tested this fix. Seems to work for
me. C
On Wed, Jul 15, 2020 at 10:48 PM Marek Szyprowski
wrote:
>
> Hi
>
> On 16.07.2020 07:30, Guenter Roeck wrote:
> > On 7/15/20 10:08 PM, Saravana Kannan wrote:
> >> Marek and Guenter reported that commit 287905e68dd2 ("driver core:
> >> Expose devic
o release the device
earlier and revert the RCU callback code to what it was before
commit 287905e68dd2 ("driver core: Expose device link details in sysfs")
Fixes: 287905e68dd2 ("driver core: Expose device link details in sysfs")
Reported-by: Marek Szyprowski
Reported-by: Guent
le. For example, device C is
- A display backlight that doesn't have a driver
- An interconnect that doesn't have an interconnect provider driver
Signed-off-by: Saravana Kannan
---
drivers/regulator/core.c | 155 ++-
include/linux/regulator/driver.h |
regulator-X voltage is NOT lowered to
1000 mV when device-C still needed it at 2000 mV.
[1] -
https://lore.kernel.org/lkml/20200605063724.9030-1-m.szyprow...@samsung.com/#t
Signed-off-by: Saravana Kannan
---
drivers/regulator/core.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions
This can be used by frameworks to set the sync_state() helper functions
for drivers that don't already have them set.
Signed-off-by: Saravana Kannan
---
include/linux/device.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
Part of the regulator_get() code is already factored out into
create_regulator(). This patch factors out some of the regulator_put()
code into destroy_regulator() so that create_regulator() has a
corresponding unwind function. Subsequent patches will use this
function.
Signed-off-by: Saravana
sync_state() support
Saravana Kannan (4):
driver core: Add dev_set_drv_sync_state()
regulator: core: Add destroy_regulator()
regulator: core: Add basic enable/disable support for sync_state()
callbacks
regulator: core: Add voltage support for sync_state() callbacks
drivers/regul
On Wed, Jul 15, 2020 at 3:14 PM Guenter Roeck wrote:
>
> Hi,
>
> On Thu, May 21, 2020 at 12:17:58PM -0700, Saravana Kannan wrote:
> > It's helpful to be able to look at device link details from sysfs. So,
> > expose it in sysfs.
> >
> > Say device
On Wed, Jul 15, 2020 at 1:22 AM Marek Szyprowski
wrote:
>
> Hi Greg and Saravana,
>
> On 10.07.2020 15:23, Greg Kroah-Hartman wrote:
> > On Mon, Jul 06, 2020 at 03:45:02PM -0700, Saravana Kannan wrote:
> >> On Tue, Jun 16, 2020 at 8:45 PM Saravana Kannan
> >&g
On Fri, Jul 10, 2020 at 6:21 AM Greg Kroah-Hartman
wrote:
>
> On Tue, Jun 30, 2020 at 10:11:01AM -0700, Saravana Kannan wrote:
> > I already have a patch to avoid deferred probe during batch fwnode
> > parsing. I'm trying to do a few more tests before I send it out. So,
On Fri, Jul 10, 2020 at 6:23 AM Greg Kroah-Hartman
wrote:
>
> On Mon, Jul 06, 2020 at 03:45:02PM -0700, Saravana Kannan wrote:
> > On Tue, Jun 16, 2020 at 8:45 PM Saravana Kannan
> > wrote:
> > >
> > > On Fri, May 29, 2020 at 5:30 AM Greg Kroah-Hartman
> &
On Wed, Jul 8, 2020 at 1:16 AM Geert Uytterhoeven wrote:
>
> Hi Rafael,
>
> On Tue, Jul 7, 2020 at 5:56 PM Rafael J. Wysocki wrote:
> > On Wed, Jul 1, 2020 at 9:43 PM Saravana Kannan wrote:
> > > When commit 93d2e4322aa7 ("of: platform: Batch fwnode parsing
On Tue, Jul 7, 2020 at 8:59 AM Rafael J. Wysocki wrote:
>
> On Wed, Jul 1, 2020 at 9:43 PM Saravana Kannan wrote:
> >
> > The current deferred probe implementation can mess up suspend/resume
> > ordering if deferred probe thread is kicked off in parallel with the
On Tue, Jun 16, 2020 at 8:45 PM Saravana Kannan wrote:
>
> On Fri, May 29, 2020 at 5:30 AM Greg Kroah-Hartman
> wrote:
> > Looks semi-sane, but it's too close to the merge window at the moment
> > for me to take this. If there's no objections by the time 5.8-rc1
On Thu, Jul 2, 2020 at 8:30 AM Ard Biesheuvel wrote:
>
> On Tue, 23 Jun 2020 at 03:27, Saravana Kannan wrote:
> >
> > When loading a module, module_frob_arch_sections() tries to figure out
> > the number of PLTs that'll be needed to handle all the RELAs. While
>
keeps track of
the devices that had their probe deferred due to fw_devlink_pause() and
attempts to probe them once during fw_devlink_resume().
Fixes: 716a7a259690 ("driver core: fw_devlink: Add support for batching fwnode
parsing")
Signed-off-by: Saravana Kannan
---
drivers/base/core
nk: Add support for batching fwnode
parsing")
Signed-off-by: Saravana Kannan
---
drivers/base/base.h | 1 -
drivers/base/core.c | 1 -
drivers/base/dd.c | 5 -
3 files changed, 7 deletions(-)
diff --git a/drivers/base/base.h b/drivers/base/base.h
index 95c22c0f9036..40fb069a8a7e 10064
The defer_sync field is used as a hook to add the device to the
deferred_sync list. Rename it so that it's more meaningful for the next
patch that'll also use this field as a hook to a deferred_fw_devlink
list.
Signed-off-by: Saravana Kannan
---
drivers/base/core
ression by avoiding the use of deferred probing
when optimizing fw_devlink parsing.
Saravana Kannan (3):
driver core: Don't do deferred probe in parallel with kernel_init
thread
driver core: Rename dev_links_info.defer_sync to defer_hook
driver core: Avoid deferred probe due to fw_devli
On Mon, Jun 29, 2020 at 9:49 PM Rajat Jain wrote:
>
> Add a new (optional) field to denote the physical location of a device
> in the system, and expose it in sysfs. This was discussed here:
> https://lore.kernel.org/linux-acpi/20200618184621.ga446...@kroah.com/
>
> (The primary choice for attribu
gt; wrote:
> > > >
> > > > Hi Saravana,
> > > >
> > > > On Fri, Jun 26, 2020 at 10:34 PM Saravana Kannan
> > > > wrote:
> > > > > On Fri, Jun 26, 2020 at 4:27 AM Rafael J. Wysocki
> > > > > wrote:
> &g
On Fri, Jun 26, 2020 at 4:27 AM Rafael J. Wysocki wrote:
>
> On Thu, Jun 25, 2020 at 7:52 PM Saravana Kannan wrote:
> >
> > On Thu, Jun 25, 2020 at 10:47 AM Rafael J. Wysocki
> > wrote:
> > >
> > > Note that deferred probing gets in the way here
On Thu, Jun 25, 2020 at 10:47 AM Rafael J. Wysocki wrote:
>
> On Thu, Jun 25, 2020 at 7:09 PM Saravana Kannan wrote:
> >
> > On Thu, Jun 25, 2020 at 10:03 AM Rafael J. Wysocki
> > wrote:
> > >
> > > On Thu, Jun 25, 2020 at 7:01 PM Saravana Kannan
&
On Thu, Jun 25, 2020 at 10:03 AM Rafael J. Wysocki wrote:
>
> On Thu, Jun 25, 2020 at 7:01 PM Saravana Kannan wrote:
> >
> > On Thu, Jun 25, 2020 at 9:58 AM Rafael J. Wysocki wrote:
> > >
> > > On Thu, Jun 25, 2020 at 6:49 PM Saravana Kannan
> > >
Dropping Feng and Toan due to mail bounces.
On Thu, Jun 25, 2020 at 1:58 AM Geert Uytterhoeven wrote:
>
> Hi Saravana,
>
> Thanks for your patch!
>
> On Thu, Jun 25, 2020 at 5:24 AM Saravana Kannan wrote:
> > Under the following conditions:
> > - driver A is b
On Thu, Jun 25, 2020 at 9:58 AM Rafael J. Wysocki wrote:
>
> On Thu, Jun 25, 2020 at 6:49 PM Saravana Kannan wrote:
> >
> > Dropping Feng Kan and Toan Le because
> > their mails are bouncing.
> >
> > On Thu, Jun 25, 2020 at 8:19 AM Rafael J. Wysocki wrote:
Dropping Feng Kan and Toan Le because
their mails are bouncing.
On Thu, Jun 25, 2020 at 8:19 AM Rafael J. Wysocki wrote:
>
> On Thu, Jun 25, 2020 at 5:24 AM Saravana Kannan wrote:
> >
> > Under the following conditions:
> > - driver A is built in and can probe devi
Add support for batching fwnode
parsing")
Cc: Geert Uytterhoeven
Signed-off-by: Saravana Kannan
---
drivers/base/dd.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 9a1d940342ac..52b2148c7983 100644
--- a/drivers/base/dd.c
+++
On Mon, Jun 22, 2020 at 8:49 AM Geert Uytterhoeven wrote:
>
> Hi Saravana,
>
> On Sat, Jun 20, 2020 at 4:33 AM Saravana Kannan wrote:
> > On Fri, Jun 19, 2020 at 1:07 PM Saravana Kannan
> > wrote:
> > > I think instead of deferred_probe_work_func() moving t
47
drm 13014 40
IPA 809763
audio 460616
gpu 652720
Total time to load all these modules: 247
Time saved during boot for just these 6 modules: 390 ms
Cc: Ard Biesheuvel
On Fri, Jun 19, 2020 at 1:07 PM Saravana Kannan wrote:
>
> I think instead of deferred_probe_work_func() moving the device to the
> end of the dpm_list, I think the device probing successfully is what
> should move it to the end of the dpm_list. That way, the dpm_list is
> actu
Snipped a bunch of old context.
On Fri, Jun 19, 2020 at 5:24 AM Geert Uytterhoeven wrote:
>
> On Fri, Jun 19, 2020 at 1:01 AM Saravana Kannan wrote:
> >
> > When you say the "The affected drivers are still probed in the same
> > order", are you only referr
On Thu, Jun 18, 2020 at 12:32 AM Geert Uytterhoeven
wrote:
>
> Hi Saravana,
>
> On Wed, Jun 17, 2020 at 8:36 PM Saravana Kannan wrote:
> > On Wed, Jun 17, 2020 at 5:20 AM Geert Uytterhoeven
> > wrote:
> > > On Fri, May 15, 2020 at 7:38 AM Saravana
On Wed, Jun 17, 2020 at 3:12 PM Rob Herring wrote:
>
> On Tue, 09 Jun 2020 18:19:34 -0700, Saravana Kannan wrote:
> > Consider this example where -> means LHS device is a consumer of RHS
> > device and indentation represents "child of" of the previous devic
On Wed, Jun 17, 2020 at 7:05 AM Will Deacon wrote:
>
> Hi all,
>
> On Wed, Jun 17, 2020 at 10:17:33AM +0200, Ard Biesheuvel wrote:
> > On Tue, 16 Jun 2020 at 23:40, Will Deacon wrote:
> > > On Fri, Jun 05, 2020 at 03:22:57PM -0700, Saravana Kannan wrote:
> > >
Hi Geert,
On Wed, Jun 17, 2020 at 5:20 AM Geert Uytterhoeven wrote:
>
> Hi Saravana,
>
> On Fri, May 15, 2020 at 7:38 AM Saravana Kannan wrote:
> > The fw_devlink_pause() and fw_devlink_resume() APIs allow batching the
> > parsing of the device tree nodes when a lot of
On Fri, May 29, 2020 at 5:30 AM Greg Kroah-Hartman
wrote:
> Looks semi-sane, but it's too close to the merge window at the moment
> for me to take this. If there's no objections by the time 5.8-rc1 is
> out, I'll queue it up in my tree for 5.9-rc1.
Another friendly reminder :)
-Saravana
On Tue, Jun 16, 2020 at 2:40 PM Will Deacon wrote:
>
> On Fri, Jun 05, 2020 at 03:22:57PM -0700, Saravana Kannan wrote:
> > When loading a module, module_frob_arch_sections() tries to figure out
> > the number of PLTs that'll be needed to handle all the RELAs. While
>
DT implementation of fw_devlink needs this function to detect cycles. So
make it available.
Signed-off-by: Saravana Kannan
---
drivers/base/core.c| 2 +-
include/linux/device.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
Patch 2/2 explain the series. Just using a cover letter to thread the
series and add CC's.
-Saravana
v1 -> v2:
Patch 2/2:
- Added more comments
- Fixed missing put_device()
- Fixed stupid fall through in the error case
Saravana Kannan (2):
driver core: Add device_is_dependent()
th this commit:
1. Device A is added.
3. Device B is added
4. Device B is linked as a consumer to Device A
5. Device A probes.
6. Device B probes because Device A has probed.
7. Device C is added and probed.
Signed-off-by: Saravana Kannan
---
drivers/of/property.c | 62 ++
rote:
> > >>> On 25/03/2020 12:51, Andy Shevchenko wrote:
> > >>>> On Tue, Mar 24, 2020 at 08:29:01PM -0700, Saravana Kannan wrote:
> > >>>>> On Tue, Mar 24, 2020 at 5:38 AM Andy Shevchenko
> > >>>>> wrote:
> > >&
On Mon, Jun 1, 2020 at 10:23 AM Mark Brown wrote:
>
> On Fri, May 29, 2020 at 07:39:33PM -0700, Saravana Kannan wrote:
> > On Fri, May 29, 2020 at 6:00 AM Mark Brown wrote:
> > > On Thu, May 28, 2020 at 12:06:10PM -0700, Saravana Kannan wrote:
>
> > > > espe
On Fri, Jun 5, 2020 at 8:59 AM Mark Brown wrote:
>
> On Fri, Jun 05, 2020 at 03:37:32PM +0200, Marek Szyprowski wrote:
> > On 05.06.2020 12:20, Mark Brown wrote:
>
> > > No, this is not what boot-on means at all. It is there for cases where
> > > we can't read the enable status from the hardware.
On Fri, Jun 5, 2020 at 5:36 PM Saravana Kannan wrote:
>
> Consider this example where -> means LHS device is a consumer of RHS
> device and indentation represents "child of" of the previous device.
>
> Device A -> Device C
>
> Device B -> Device A
>
it:
1. Device A is added.
3. Device B is added
4. Device B is linked as a consumer to Device A
5. Device A probes.
6. Device B probes because Device A has probed.
7. Device C is added and probed.
Signed-off-by: Saravana Kannan
---
drivers/of/property.c | 44
Patch 2/2 explain the series. Just using a cover letter to thread the
series and add CC's.
-Saravana
Saravana Kannan (2):
driver core: Add device_is_dependent() to linux/device.h
of: property: Improve cycle detection when one of the devices is never
added
drivers/base/core.c
DT implementation of fw_devlink needs this function to detect cycles. So
make it available.
Signed-off-by: Saravana Kannan
---
drivers/base/core.c| 2 +-
include/linux/device.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
R_AARCH64_JUMP26 if it's disabled.
Cc: Ard Biesheuvel
Signed-off-by: Saravana Kannan
---
arch/arm64/kernel/module-plts.c | 37 -
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/module-plts.c b/arch/arm64/kernel/module-plts.c
in
Hi John,
On Fri, Jun 5, 2020 at 2:19 PM John Stultz wrote:
>
> From: Saravana Kannan
>
> When setting the of_node for a newly created device, also set the
> fwnode. This allows fw_devlink to work for slimbus devices.
>
> Cc: Srinivas Kandagatla
> Cc: alsa-de...@alsa-pro
On Fri, May 1, 2020 at 1:23 PM Saravana Kannan wrote:
>
> On Fri, May 1, 2020 at 1:48 AM Marc Zyngier wrote:
> >
> > On 2020-04-29 20:04, Saravana Kannan wrote:
> > > On Wed, Apr 29, 2020 at 2:28 AM Marc Zyngier wrote:
> >
> > [...]
> >
> > &
The following commit has been merged into the timers/core branch of tip:
Commit-ID: 7a3768c206a006525afc090f92d4d618d8356b92
Gitweb:
https://git.kernel.org/tip/7a3768c206a006525afc090f92d4d618d8356b92
Author:Saravana Kannan
AuthorDate:Tue, 24 Mar 2020 12:53:02 -07:00
On Fri, May 29, 2020 at 6:00 AM Mark Brown wrote:
>
> On Thu, May 28, 2020 at 12:06:10PM -0700, Saravana Kannan wrote:
> > When a regulator is left on by the bootloader or anything else before
> > the kernel starts (let's call this a "boot on" regulator), we ne
On Thu, May 21, 2020 at 12:18 PM Saravana Kannan wrote:
>
> With fw_devlink and with sync_state() callback features, there's a lot
> of device/device link related information that's not available in sysfs.
>
> Exposing these details to user space can be very useful i
ers after
the timeout expires.
- Made every regulator driver add sync_state() support
Saravana Kannan (2):
driver core: Add dev_set_drv_sync_state()
regulator: Add support for sync_state() callbacks
drivers/regulator/core.c | 112 +++
include/linux/d
or_sync_state,
Once that's done, then for any device that's probed by the driver, all
the "boot on" regulators supplied by the device will be kept on till all
the consumers of the device have probed. Once the consumers have probed,
the "boot on" regulators would
This can be used by frameworks to set the sync_state() helper functions
for drivers that don't already have them set.
Signed-off-by: Saravana Kannan
---
I'm hoping I can drop this patch based on discussions in patch 1/2.
include/linux/device.h | 12
1 file changed, 12
On Wed, May 27, 2020 at 1:26 AM Rafael J. Wysocki wrote:
>
> On Wed, May 27, 2020 at 12:09 AM Saravana Kannan wrote:
> >
> > When SYNC_STATE_ONLY support was added in commit 05ef983e0d65 ("driver
> > core: Add device link support for SYNC_STATE_ONLY flag"),
>
On Wed, May 27, 2020 at 1:34 PM Mark Brown wrote:
>
> On Wed, May 27, 2020 at 10:17:21AM -0700, Saravana Kannan wrote:
>
> > If fw_devlink is off or not supported by the firmware (Eg: ACPI), the
> > behavior doesn't change. We act as if there are no consumers and tu
On Wed, May 27, 2020 at 8:38 AM Rob Clark wrote:
>
> On Wed, May 27, 2020 at 1:47 AM Sharat Masetty
> wrote:
> >
> > + more folks
> >
> > On 5/18/2020 9:55 PM, Rob Clark wrote:
> > > On Mon, May 18, 2020 at 7:23 AM Jordan Crouse
> > > wrote:
> > >> On Thu, May 14, 2020 at 04:24:18PM +0530, Sha
On Wed, May 27, 2020 at 4:17 AM Mark Brown wrote:
>
> On Wed, May 27, 2020 at 12:40:56AM -0700, Saravana Kannan wrote:
>
> > When a regulator is left on by the bootloader or anything else before
> > the kernel starts (let's call this a "boot on" regulator), we
or_sync_state,
Once that's done, then for any device that's probed by the driver, all
the "boot on" regulators supplied by the device will be kept on till all
the consumers of the device have probed. Once the consumers have probed,
the "boot on" regulators would
re: Fix SYNC_STATE_ONLY device link
implementation")
Reported-by: Michael Walle
Tested-by: Michael Walle
Signed-off-by: Saravana Kannan
---
v1->v2:
- Added code to "revert" the link status if consumer probe fails
v2->v3:
- Fixed copy-pasta
On Tue, May 26, 2020 at 2:53 PM Michael Walle wrote:
>
> Am 2020-05-26 23:45, schrieb Saravana Kannan:
> > On Tue, May 26, 2020 at 2:13 PM Michael Walle wrote:
> >>
> >> Am 2020-05-26 21:43, schrieb Saravana Kannan:
> >> > When SYNC_STATE_ONLY support
On Tue, May 26, 2020 at 2:13 PM Michael Walle wrote:
>
> Am 2020-05-26 21:43, schrieb Saravana Kannan:
> > When SYNC_STATE_ONLY support was added in commit 05ef983e0d65 ("driver
> > core: Add device link support for SYNC_STATE_ONLY flag"),
> > SYNC_STATE_
re: Fix SYNC_STATE_ONLY device link
implementation")
Reported-by: Michael Walle
Signed-off-by: Saravana Kannan
---
v1->v2:
- Added code to "revert" the link status if consumer probe fails
Greg,
I think this is the issue Michael ran into. I'd like him to test the fix
befor
On Tue, May 26, 2020 at 4:04 AM Michael Walle wrote:
>
> Hi Saravana,
>
> Am 2020-05-26 09:07, schrieb Saravana Kannan:
> >> Greg,
> >>
> >> I think this is the issue Michael ran into. I'd like him to test the
> >> fix
> >> before it&
On Tue, May 26, 2020 at 12:05 AM Saravana Kannan wrote:
>
> When SYNC_STATE_ONLY support was added in commit 05ef983e0d65 ("driver
> core: Add device link support for SYNC_STATE_ONLY flag"),
> SYNC_STATE_ONLY links were treated similar to STATELESS links in terms
> of no
3b3c9ed6@apollo/
Fixes: 05ef983e0d65 ("driver core: Add device link support for SYNC_STATE_ONLY
flag")
Fixes: 21c27f06587d ("driver core: Fix SYNC_STATE_ONLY device link
implementation")
Reported-by: Michael Walle
Signed-off-by: Saravana Kannan
---
Greg,
I think this is the issu
On Mon, May 25, 2020 at 12:05 PM Michael Walle wrote:
>
> Am 2020-05-25 20:39, schrieb Saravana Kannan:
> > On Mon, May 25, 2020 at 4:31 AM Michael Walle wrote:
> >>
> >> Am 2020-05-23 00:47, schrieb Michael Walle:
> >> > Am 2020-05-23 00:21, schrieb Sar
On Mon, May 25, 2020 at 4:31 AM Michael Walle wrote:
>
> Am 2020-05-23 00:47, schrieb Michael Walle:
> > Am 2020-05-23 00:21, schrieb Saravana Kannan:
> >> On Fri, May 22, 2020 at 11:41 AM Michael Walle
> >> wrote:
> >>>
> >>> Am Mon, 18
On Fri, May 22, 2020 at 11:41 AM Michael Walle wrote:
>
> Am Mon, 18 May 2020 23:30:00 -0700
> schrieb Saravana Kannan :
>
> > When SYNC_STATE_ONLY support was added in commit 05ef983e0d65 ("driver
> > core: Add device link support for SYNC_STATE_ONLY flag"),
Also, this file is removed once the device probes as it's no
longer relevant.
Signed-off-by: Saravana Kannan
---
.../sysfs-devices-waiting_for_supplier| 17
drivers/base/core.c | 26 +++
2 files changed, 43 insertions(+)
create m
atus file.
Patch 3/4
- Fixed error handling that Greg pointed out before.
Patch 4/4
- New patch
v2->v3:
- Dropped patch 1/4 from v2 since it was already picked up. So numbering
has shifted.
Patch 1/3
- Added documentation
Saravana Kannan (3):
driver core: Expose device link details in sys
To get a list of all the device link in the system:
ls /sys/class/devlink/
To get the consumer names and links of a device:
ls -d /sys/devices/.../device-X/consumer:*
To get the supplier names and links of a device:
ls -d /sys/devices/.../device-X/supplier:*
Signed-off-by: Saravana Kannan
---
enabled because
they were left enabled by the bootloader and all its consumers haven't
probed yet.
Signed-off-by: Saravana Kannan
---
.../ABI/testing/sysfs-devices-state_synced| 24 +++
drivers/base/dd.c | 22 +
2 files change
On Thu, May 21, 2020 at 2:42 AM Greg Kroah-Hartman
wrote:
>
> On Tue, May 19, 2020 at 08:48:20PM -0700, Saravana Kannan wrote:
> > With fw_devlink and with sync_state() callback features, there's a lot
> > of device/device link related information that's not availabl
On Wed, May 20, 2020 at 11:51 AM Sibi Sankar wrote:
>
> On 2020-05-20 01:27, Saravana Kannan wrote:
> > On Tue, May 19, 2020 at 11:58 AM Rob Herring wrote:
> >>
> >> On Tue, May 12, 2020 at 03:53:26PM +0300, Georgi Djakov wrote:
> >> > From: Sibi S
On Tue, May 19, 2020 at 9:36 PM Saravana Kannan wrote:
>
> Commit 21c27f06587d ("driver core: Fix SYNC_STATE_ONLY device link
> implementation") didn't completely fix STATELESS + SYNC_STATE_ONLY
> handling.
>
> What looks like an optimization in that commit is a
s
reordering of devices in the dpm_list when a DL_FLAG_STATELESS device
link is create on top of an existing DL_FLAG_SYNC_STATE_ONLY device
link.
Fixes: 21c27f06587d ("driver core: Fix SYNC_STATE_ONLY device link
implementation")
Signed-off-by: Saravana Kannan
---
Sigh... device links a
Also, this file is removed once the device probes as it's no
longer relevant.
Signed-off-by: Saravana Kannan
---
.../sysfs-devices-waiting_for_supplier| 17
drivers/base/core.c | 26 +++
2 files changed, 43 insertions(+)
create m
To get a list of all the device link in the system:
ls /sys/class/devlink/
To get the consumer names and links of a device:
ls -d /sys/devices/.../device-X/consumer:*
To get the supplier names and links of a device:
ls -d /sys/devices/.../device-X/supplier:*
Signed-off-by: Saravana Kannan
---
dr
401 - 500 of 1001 matches
Mail list logo
