History log of /u-boot/doc/imx/clk/ccf.txt
Revision Date Author Comments
# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 41575d8e 03-Dec-2020 Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 78ce0bd3 24-Jun-2020 Sean Anderson <seanga2@gmail.com>

clk: Always use the supplied struct clk

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could
cause problems with composite clocks. The individual clocks in a composite
clock did not have the ->dev field filled in. This was fine, because the
device-specific clock information would be used. However, since there was
no ->dev, there was no way to get the parent clock. This caused the
recalc_rate method of the CCF divider clock to fail. One option would be to
use the clk->priv field to get the composite clock and from there get the
appropriate parent device. However, this would tie the implementation to
the composite clock. In general, different devices should not rely on the
contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied
struct clock. The composite clock now fills in the ->dev pointer of its
child clocks. This allows child clocks to make calls like clk_get_parent()
without issue.

imx avoided the above problem by using a custom get_rate function with
composite clocks.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>


# 4ebdf654 24-Jun-2019 Lukasz Majewski <lukma@denx.de>

clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski <lukma@denx.de>