On Wed, May 31, 2023 at 12:38:20AM +0900, Masahiro Yamada wrote:
> On Tue, May 30, 2023 at 9:38 PM Sascha Hauer wrote:
> >
> > Picked some outdated address from Masahiro, so once again:
>
>
> The macro name is misleading - perhaps, it should have
> been named as __is_defined_as_1().
>
> I do no
On Wed, May 31, 2023 at 08:27:01AM +0200, Ahmad Fatoum wrote:
> Other boards already have sdram-init.bin in their .gitignore, so have
> quartz64 follow suit.
>
> Signed-off-by: Ahmad Fatoum
> ---
> arch/arm/boards/pine64-quartz64/.gitignore | 1 +
> 1 file changed, 1 insertion(+)
> create mode
Hi Ahmad,
Thanks again for your prompt reply and accurate tips!
Took the following changes:
1. Increasing the DRAM size to 128MB (let barebox start from 0).
2. Set PBL stack to offset 2MB from DRAM
3. Fix the device tree "memory" entry to have 128MB.
4. Load barebox-spider-mk1-evk.img to SRAM and
Hi Lior,
On 31.05.23 10:05, Lior Weintraub wrote:
> Hi Ahmad,
>
> Thanks again for your prompt reply and accurate tips!
> Took the following changes:
> 1. Increasing the DRAM size to 128MB (let barebox start from 0).
> 2. Set PBL stack to offset 2MB from DRAM
Just use end of SRAM, so you are com
We used skip setting up the zero page as faulting when the SDRAM
starts at 0x0. One reason for doing that was that ATAGs will be copied
there in that case. Call zero_page_access() if necessary to be able
to set the zero page to faulting during barebox startup in the next
step.
Signed-off-by: Sasch
We used to skip setting the zero page to faulting when SDRAM starts
at 0x0. As bootm code now explicitly sets the zero page accessible
before copying ATAGs there this should no longer be necessary, so
unconditionally set the zero page to faulting during MMU startup.
This also moves the zero page se
On 31.05.23 12:01, Sascha Hauer wrote:
> We used skip setting up the zero page as faulting when the SDRAM
> starts at 0x0. One reason for doing that was that ATAGs will be copied
> there in that case. Call zero_page_access() if necessary to be able
> to set the zero page to faulting during barebox
Hello Sascha,
On 31.05.23 12:01, Sascha Hauer wrote:
> We used to skip setting the zero page to faulting when SDRAM starts
> at 0x0. As bootm code now explicitly sets the zero page accessible
> before copying ATAGs there this should no longer be necessary, so
> unconditionally set the zero page to
This reverts commit d13d870986eeecc58d8652268557e4a159b9d4c4.
While the patch itself is correct, it at least breaks USB on the
Raspberry Pi 3b.
With this patch dma_sync_single_for_device() is passed the DMA address.
This is correct as even the prototype suggests that it should get a
dma_addr_t. U
From: Ahmad Fatoum
Newer GCC versions correctly warn that the buffer allocated by realloc
is too small. Correct the size.
Signed-off-by: Ahmad Fatoum
Link: https://lore.barebox.org/20230531062703.670521-3-ah...@a3f.at
Signed-off-by: Sascha Hauer
---
scripts/omap3-usb-loader.c | 2 +-
1 file c
We used skip setting up the zero page as faulting when the SDRAM
starts at 0x0. One reason for doing that was that ATAGs will be copied
there in that case. Call zero_page_access() if necessary to be able
to set the zero page to faulting during barebox startup in the next
step.
Signed-off-by: Sasch
On 31.05.23 12:23, Sascha Hauer wrote:
> This reverts commit d13d870986eeecc58d8652268557e4a159b9d4c4.
>
> While the patch itself is correct, it at least breaks USB on the
> Raspberry Pi 3b.
>
> With this patch dma_sync_single_for_device() is passed the DMA address.
> This is correct as even the
We used skip setting up the zero page as faulting when the SDRAM
starts at 0x0. One reason for doing that was that ATAGs will be copied
there in that case. Call zero_page_access() if necessary to be able
to set the zero page to faulting during barebox startup in the next
step.
Signed-off-by: Sasch
We used to skip setting the zero page to faulting when SDRAM starts
at 0x0. As bootm code now explicitly sets the zero page accessible
before copying ATAGs there this should no longer be necessary, so
unconditionally set the zero page to faulting during MMU startup.
This also moves the zero page se
Gna, forget this. Wrong patches sent.
Sascha
On Wed, May 31, 2023 at 12:26:08PM +0200, Sascha Hauer wrote:
> From: Ahmad Fatoum
>
> Newer GCC versions correctly warn that the buffer allocated by realloc
> is too small. Correct the size.
>
> Signed-off-by: Ahmad Fatoum
> Link: https://lore.bar
On 31.05.23 12:35, Sascha Hauer wrote:
> We used skip setting up the zero page as faulting when the SDRAM
> starts at 0x0. One reason for doing that was that ATAGs will be copied
> there in that case. Call zero_page_access() if necessary to be able
> to set the zero page to faulting during barebox
On 31.05.23 12:35, Sascha Hauer wrote:
> We used to skip setting the zero page to faulting when SDRAM starts
> at 0x0. As bootm code now explicitly sets the zero page accessible
> before copying ATAGs there this should no longer be necessary, so
> unconditionally set the zero page to faulting durin
On Wed, May 31, 2023 at 12:45:17PM +0200, Ahmad Fatoum wrote:
> On 31.05.23 12:35, Sascha Hauer wrote:
> > We used to skip setting the zero page to faulting when SDRAM starts
> > at 0x0. As bootm code now explicitly sets the zero page accessible
> > before copying ATAGs there this should no longer
Hello Sascha,
On 31.05.23 13:21, Sascha Hauer wrote:
> On Wed, May 31, 2023 at 12:45:17PM +0200, Ahmad Fatoum wrote:
>> On 31.05.23 12:35, Sascha Hauer wrote:
>>> We used to skip setting the zero page to faulting when SDRAM starts
>>> at 0x0. As bootm code now explicitly sets the zero page accessi
On Wed, May 31, 2023 at 01:58:33PM +0200, Ahmad Fatoum wrote:
> > From b6e5c92682467496bd9c57918996f1feffda2dd6 Mon Sep 17 00:00:00 2001
> > From: Sascha Hauer
> > Date: Wed, 31 May 2023 11:58:51 +0200
> > Subject: [PATCH] ARM: mmu_32: fix setting up zero page when it is in SDRAM
> >
> > We used
On 31.05.23 14:38, Sascha Hauer wrote:
> On Wed, May 31, 2023 at 01:58:33PM +0200, Ahmad Fatoum wrote:
>>> From b6e5c92682467496bd9c57918996f1feffda2dd6 Mon Sep 17 00:00:00 2001
>>> From: Sascha Hauer
>>> Date: Wed, 31 May 2023 11:58:51 +0200
>>> Subject: [PATCH] ARM: mmu_32: fix setting up zero p
Hi!
>
> On 31.05.23 12:23, Sascha Hauer wrote:
> > This reverts commit d13d870986eeecc58d8652268557e4a159b9d4c4.
> >
> > While the patch itself is correct, it at least breaks USB on the
> > Raspberry Pi 3b.
> >
> > With this patch dma_sync_single_for_device() is passed the DMA address.
> > This is
Hello Denis,
On 31.05.23 15:02, Denis Orlov wrote:
> Hi!
>
>>
>> On 31.05.23 12:23, Sascha Hauer wrote:
>>> This reverts commit d13d870986eeecc58d8652268557e4a159b9d4c4.
>>>
>>> While the patch itself is correct, it at least breaks USB on the
>>> Raspberry Pi 3b.
>>>
>>> With this patch dma_sync_
cdev links are not symlinks and cdev_by_name will always resolve them.
As the barebox stat command is a convenience for VFS developers, it's
useful to have the command identify links, so let's teach it just that.
There's no behavior difference between specifying -L and not. This
should be rather a
This aligns behavior with usual implementations of stat.
Signed-off-by: Ahmad Fatoum
---
fs/fs.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/fs/fs.c b/fs/fs.c
index 368458cc54f8..311571ba3088 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -130,8 +130,6 @@ void s
From: Yegor Yefremov
Signed-off-by: Yegor Yefremov
---
drivers/net/phy/Kconfig | 5 ++
drivers/net/phy/Makefile| 1 +
drivers/net/phy/motorcomm.c | 128
3 files changed, 134 insertions(+)
create mode 100644 drivers/net/phy/motorcomm.c
diff --gi
The #ifdef __BAREBOX__ is meant for easier synchronization with
dt-utils. We'll keep that intact, but move it out of the function to not
break reading flow. After sync, dt-utils would now need to implement
of_cdev_find
cdev_to_devpath
Signed-off-by: Ahmad Fatoum
---
common/state/state.c | 3
Later code will make it possible to define a on-disk-described partition
in the DT as well. For this reason, we can't assumed
DEVFS_PARTITION_FROM_TABLE to mean !DT, so let's add a dedicated flag
for that.
Signed-off-by: Ahmad Fatoum
---
drivers/of/partition.c | 5 +++--
fs/fs.c|
The macro parameter 'c' was never used, instead hardcoding cdev.
It worked so far anyway, because all users of for_each_cdev used cdev
as the argument. Fix this.
Signed-off-by: Ahmad Fatoum
---
include/driver.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/driver.h
stat prints a line with partitioning/type info for cdevs, but not all
cdevs have these, so we want to skip printing when it's empty.
Instead of duplicating the check, just utilize printf returning the
number of characters written.
Signed-off-by: Ahmad Fatoum
---
fs/fs.c | 20
We look too much into struct cdev's guts. Let's add helpers to make
operating on block device cdevs more concise.
Signed-off-by: Ahmad Fatoum
---
include/block.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/include/block.h b/include/block.h
index 4dd2aa1f80ef..da258f509b4
__of_find_path goes throught the hassle of determining the cdev, only to
discard it again and return either zero or an error code.
Follow up commits will need to get the cdev corresponding to a path in
the DT. So let's make that easier by exporting a suitable helper function.
Signed-off-by: Ahmad
dos_partition_type == 0 can mean that either a partition is not
a MBR partition or that it indeed has a partition type of 0x00.
In preparation for using that field in a union, explicitly check if we
have a MBR partition.
Signed-off-by: Ahmad Fatoum
---
common/blspec.c | 2 +-
fs/fs.c |
Currently, the only way to differentiate between a GPT disk and a MBR
one is to check whether the cdev's device has a guid (=> GPT) or a
nt_signature (=> MBR) device parameter. We already have a flag parameter
though, so let's record this info there for easy retrieval.
We intentionally don't use t
We already record DOS partition type in cdev, so let's do the same for
GPT Type UUID. This will be used in a later commit to identify
barebox-state partitions.
Signed-off-by: Ahmad Fatoum
---
common/partitions.c| 2 +-
common/partitions/efi.c| 1 +
common/partitions/parser.h | 5
of_find_path may be called on a partition, whose parent device is not
yet probed. state code solves that by calling of_partition_ensure_probed
before of_find_path_by_nde, but really we should be doing that for all
calls to of_find_path. Do so.
Signed-off-by: Ahmad Fatoum
---
common/state/state.c
Every instance where we register a block device, it's followed by an
attempt to parse the partition table, most often with a warning when
it fails. Thus let's move partition table parsing into
blockdevice_register.
Signed-off-by: Ahmad Fatoum
---
arch/sandbox/board/hostfile.c | 4
common/bl
So far, we had basically three ways to reference barebox,state on block
devices:
- On platforms with device tree, we point at a fixed partition
described in the DT
- On platforms without device tree, we have a custom binding that
does a global lookup by partuuid (or a more obscure one
Let's sync definition with Linux, so we are able to pass efi_guid_t
types to function accepting guid_t. This has the added benefit of us
starting to observe alignment, which may become relevant with barebox
EFI on non-x86.
Signed-off-by: Ahmad Fatoum
---
include/efi.h | 19 +++
1
The backend device tree property so far always pointed at a partition.
Let's allow pointing it at GPT storage devices directly and lookup
the correct barebox state partition by the well-known type GUID:
4778ed65-bf42-45fa-9c5b-287a1dc4aab1
Signed-off-by: Ahmad Fatoum
---
common/state/state.c
We have three UUID/GUID definitions in barebox:
- efi_guid_t: for EFI GUIDs
- uuid_t: for RFC 4122/DCE 1.1 (Variant 1) UUIDs
- guid_t: Apparently UUIDs stored in little-endian
In preparation for switching efi_guid_t to be a special case of guid_t
like in Linux, let's replace non-EFI us
Starting with commit 7f9f45b9bfef ("devfs: Do not create overlapping
partitions"), any overlapping is disallowed. Overlapping can be useful
though to bridge the gap between partition described in DT and via
on-disk partition tables. Let's handle the case of identical partitions
specially and have i
The UUID field has different meanings:
For a master cdev:
- GPT Header DiskGUID if GPT-formatted
- MBR Header NT Disk Signature if MBR-formatted
For a partition cdev:
- GPT UniquePartitionGUID
- MBR Header NT Disk Signature followed by "-${partititon_number}"
Later code will add yet an
barebox-state code uses of_partition_ensure_probed to resolve the
backend property. We want to allow backend to point directly at a
storage device instead of a partition. We can't determine whether a DT
device is a storage device though before it's probed, so let's have
of_partition_ensure_probed s
Partitions will have cdev->master != NULL, so often code will just do
if (cdev->master) to check if a cdev is a partition. This is suboptimal
as it may be misinterpreted by readers as meaning that the cdev is the
master device, while it's the other way round.
Let's define cdev_is_partition instead
On 23-05-31, Ahmad Fatoum wrote:
> The macro parameter 'c' was never used, instead hardcoding cdev.
> It worked so far anyway, because all users of for_each_cdev used cdev
> as the argument. Fix this.
>
> Signed-off-by: Ahmad Fatoum
Reviewed-by: Marco Felsch
> ---
> include/driver.h | 2 +-
>
Hi Ahmad,
Using end of SRAM as PBL stack is currently not working because we need 40bit
address (0xC0_0020_).
This needs a fix to ENTRY_FUNCTION_WITHSTACK macro.
I tried just to change const u32 __stack_top = (stack_top); to const u64
__stack_top = (stack_top); but there were linking errors
Hi Ahmad,
On 23-05-31, Ahmad Fatoum wrote:
> barebox-state code uses of_partition_ensure_probed to resolve the
> backend property. We want to allow backend to point directly at a
> storage device instead of a partition. We can't determine whether a DT
> device is a storage device though before it'
Hi Ahmad,
On 23-05-31, Ahmad Fatoum wrote:
> of_find_path may be called on a partition, whose parent device is not
> yet probed. state code solves that by calling of_partition_ensure_probed
> before of_find_path_by_nde, but really we should be doing that for all
nit: of_find_path_by_node
> calls
On 23-05-31, Ahmad Fatoum wrote:
> Partitions will have cdev->master != NULL, so often code will just do
> if (cdev->master) to check if a cdev is a partition. This is suboptimal
> as it may be misinterpreted by readers as meaning that the cdev is the
> master device, while it's the other way round
On 23-05-31, Ahmad Fatoum wrote:
> stat prints a line with partitioning/type info for cdevs, but not all
> cdevs have these, so we want to skip printing when it's empty.
> Instead of duplicating the check, just utilize printf returning the
> number of characters written.
>
> Signed-off-by: Ahmad F
On 23-05-31, Ahmad Fatoum wrote:
> The UUID field has different meanings:
>
> For a master cdev:
>
> - GPT Header DiskGUID if GPT-formatted
> - MBR Header NT Disk Signature if MBR-formatted
>
> For a partition cdev:
>
> - GPT UniquePartitionGUID
> - MBR Header NT Disk Signature followed
Hi Ahmad,
On 23-05-31, Ahmad Fatoum wrote:
> Later code will make it possible to define a on-disk-described partition
> in the DT as well. For this reason, we can't assumed
> DEVFS_PARTITION_FROM_TABLE to mean !DT, so let's add a dedicated flag
> for that.
>
> Signed-off-by: Ahmad Fatoum
> ---
>
Hi Ahmad,
On 23-05-31, Ahmad Fatoum wrote:
> Starting with commit 7f9f45b9bfef ("devfs: Do not create overlapping
> partitions"), any overlapping is disallowed. Overlapping can be useful
> though to bridge the gap between partition described in DT and via
> on-disk partition tables. Let's handle t
On 23-05-31, Ahmad Fatoum wrote:
> Every instance where we register a block device, it's followed by an
> attempt to parse the partition table, most often with a warning when
> it fails. Thus let's move partition table parsing into
> blockdevice_register.
>
> Signed-off-by: Ahmad Fatoum
Reviewed
On 23-05-31, Ahmad Fatoum wrote:
> Currently, the only way to differentiate between a GPT disk and a MBR
> one is to check whether the cdev's device has a guid (=> GPT) or a
> nt_signature (=> MBR) device parameter. We already have a flag parameter
> though, so let's record this info there for easy
On 23-05-31, Ahmad Fatoum wrote:
> We look too much into struct cdev's guts. Let's add helpers to make
> operating on block device cdevs more concise.
>
> Signed-off-by: Ahmad Fatoum
Reviewed-by: Marco Felsch
> ---
> include/block.h | 15 +++
> 1 file changed, 15 insertions(+)
>
On 23-05-31, Ahmad Fatoum wrote:
> __of_find_path goes throught the hassle of determining the cdev, only to
> discard it again and return either zero or an error code.
>
> Follow up commits will need to get the cdev corresponding to a path in
> the DT. So let's make that easier by exporting a suit
ENTRY_FUNCTION_WITHSTACK was written with the naive assumption that
there will always be some memory in the first 32-bit of the address
space to be used as early stack. There are SoCs out there though with
sole on-chip SRAM > 4G. Accommodate this by accepting full 64-bit stack
pointers in ENTRY_FUN
Hi Ahmad,
On 23-05-31, Ahmad Fatoum wrote:
> The #ifdef __BAREBOX__ is meant for easier synchronization with
> dt-utils. We'll keep that intact, but move it out of the function to not
> break reading flow. After sync, dt-utils would now need to implement
>
> of_cdev_find
> cdev_to_devpath
>
Hi Lior,
On 31.05.23 18:13, Lior Weintraub wrote:
> Hi Ahmad,
>
> Using end of SRAM as PBL stack is currently not working because we need 40bit
> address (0xC0_0020_).
> This needs a fix to ENTRY_FUNCTION_WITHSTACK macro.
Ah, right. I just sent an (untested) patch. Would be cool if you coul
On 31.05.23 19:55, Ahmad Fatoum wrote:
> Hi Lior,
>
> On 31.05.23 18:13, Lior Weintraub wrote:
>> Hi Ahmad,
>>
>> Using end of SRAM as PBL stack is currently not working because we need
>> 40bit address (0xC0_0020_).
>> This needs a fix to ENTRY_FUNCTION_WITHSTACK macro.
>
> Ah, right. I jus
On 23-05-31, Ahmad Fatoum wrote:
> dos_partition_type == 0 can mean that either a partition is not
> a MBR partition or that it indeed has a partition type of 0x00.
>
> In preparation for using that field in a union, explicitly check if we
> have a MBR partition.
>
> Signed-off-by: Ahmad Fatoum
Hi Ahmad,
On 23-05-31, Ahmad Fatoum wrote:
> The backend device tree property so far always pointed at a partition.
> Let's allow pointing it at GPT storage devices directly and lookup
> the correct barebox state partition by the well-known type GUID:
>
> 4778ed65-bf42-45fa-9c5b-287a1dc4aab1
w
Hello Marco,
On 31.05.23 18:30, Marco Felsch wrote:
> Hi Ahmad,
>
> On 23-05-31, Ahmad Fatoum wrote:
>> barebox-state code uses of_partition_ensure_probed to resolve the
>> backend property. We want to allow backend to point directly at a
>> storage device instead of a partition. We can't determi
Hello Marco,
On 31.05.23 19:23, Marco Felsch wrote:
> Hi Ahmad,
>
> On 23-05-31, Ahmad Fatoum wrote:
>> Starting with commit 7f9f45b9bfef ("devfs: Do not create overlapping
>> partitions"), any overlapping is disallowed. Overlapping can be useful
>> though to bridge the gap between partition desc
On 31.05.23 19:33, Marco Felsch wrote:
> On 23-05-31, Ahmad Fatoum wrote:
>> Currently, the only way to differentiate between a GPT disk and a MBR
>> one is to check whether the cdev's device has a guid (=> GPT) or a
>> nt_signature (=> MBR) device parameter. We already have a flag parameter
>> tho
On 31.05.23 19:54, Marco Felsch wrote:
> Hi Ahmad,
>
> On 23-05-31, Ahmad Fatoum wrote:
>> The #ifdef __BAREBOX__ is meant for easier synchronization with
>> dt-utils. We'll keep that intact, but move it out of the function to not
>> break reading flow. After sync, dt-utils would now need to imple
On 31.05.23 20:54, Marco Felsch wrote:
> On 23-05-31, Ahmad Fatoum wrote:
>> dos_partition_type == 0 can mean that either a partition is not
>> a MBR partition or that it indeed has a partition type of 0x00.
>>
>> In preparation for using that field in a union, explicitly check if we
>> have a MBR
On 31.05.23 22:01, Marco Felsch wrote:
> Hi Ahmad,
>
> On 23-05-31, Ahmad Fatoum wrote:
>> The backend device tree property so far always pointed at a partition.
>> Let's allow pointing it at GPT storage devices directly and lookup
>> the correct barebox state partition by the well-known type GUID
Hi Sascha,
Thanks for your review
On Tue, May 30, 2023 at 10:42:36AM +0200, Sascha Hauer wrote:
> On Thu, May 25, 2023 at 01:43:26AM +0200, Jules Maselbas wrote:
> > Signed-off-by: Jules Maselbas
> > ---
> > arch/arm/boards/Makefile| 1 +
> > arch/arm/boards/pine64-pinepho
On 01.06.23 07:08, Ahmad Fatoum wrote:
> On 31.05.23 19:33, Marco Felsch wrote:
>> On 23-05-31, Ahmad Fatoum wrote:
>>> Currently, the only way to differentiate between a GPT disk and a MBR
>>> one is to check whether the cdev's device has a guid (=> GPT) or a
>>> nt_signature (=> MBR) device param
On 01.06.23 07:50, Jules Maselbas wrote:
> Hi Sascha,
>
> Thanks for your review
>
> On Tue, May 30, 2023 at 10:42:36AM +0200, Sascha Hauer wrote:
>> On Thu, May 25, 2023 at 01:43:26AM +0200, Jules Maselbas wrote:
>>> Signed-off-by: Jules Maselbas
>>> ---
>>> arch/arm/boards/Makefile
On Tue, May 30, 2023 at 10:14:20AM +0200, Sascha Hauer wrote:
> On Thu, May 25, 2023 at 01:43:24AM +0200, Jules Maselbas wrote:
> > This driver is adapted from different sources: Linux, u-boot and p-boot.
> > The latter, p-boot (forked from u-boot), is a bootloader for pinephones.
> >
> > It curre
On Thu, Jun 01, 2023 at 08:00:47AM +0200, Ahmad Fatoum wrote:
> On 01.06.23 07:50, Jules Maselbas wrote:
> > Hi Sascha,
> >
> > Thanks for your review
> >
> > On Tue, May 30, 2023 at 10:42:36AM +0200, Sascha Hauer wrote:
> >> On Thu, May 25, 2023 at 01:43:26AM +0200, Jules Maselbas wrote:
> >>> S
On 25.05.23 01:43, Jules Maselbas wrote:
> On sunxi platforms the boot rom (BROM) looks for a specific header which
> will also be loaded in memory, causing pbl, or barebox, image not loaded
> at the expected BASE addresse. This also cause an issue with relocatable
> pbl: instruction used for reloc
On 01.06.23 08:19, Jules Maselbas wrote:
> On Thu, Jun 01, 2023 at 08:00:47AM +0200, Ahmad Fatoum wrote:
>> On 01.06.23 07:50, Jules Maselbas wrote:
>>> Hi Sascha,
>>>
>>> Thanks for your review
>>>
>>> On Tue, May 30, 2023 at 10:42:36AM +0200, Sascha Hauer wrote:
On Thu, May 25, 2023 at 01:43
On Wed, May 31, 2023 at 02:40:13PM +0200, Ahmad Fatoum wrote:
> On 31.05.23 14:38, Sascha Hauer wrote:
> > On Wed, May 31, 2023 at 01:58:33PM +0200, Ahmad Fatoum wrote:
> >>> From b6e5c92682467496bd9c57918996f1feffda2dd6 Mon Sep 17 00:00:00 2001
> >>> From: Sascha Hauer
> >>> Date: Wed, 31 May 202
On Wed, May 31, 2023 at 08:29:23AM +0200, Ahmad Fatoum wrote:
> Starting with commit 324bd9bbe7e8 ("regulator: recursively enable/disable
> regulator dependency tree"), regulator operations may affect more than
> just the one regulator being enabled. Place a debug print, so it's
> easier to follow
79 matches
Mail list logo