gt; is defined on the command line.
> What happens in my case is console_on_rootfs() doesn't find
> /dev/console and switching to ttynull. /dev is not present because
> devtmpfs doesn't automount for initramfs.
But our initramfs/cpio logic ensures that the initramfs has a static
/dev/console device node, so how can that be?
https://git.buildroot.net/buildroot/tree/fs/cpio/cpio.mk#n25
--
Bye, Peter Korsgaard
ot;i2c: ocores: add polling mode workaround
> for Sifive FU540-C000 SoC")
> Signed-off-by: Sagar Shrikant Kadam
LGTM, thanks.
Acked-by: Peter Korsgaard
--
Bye, Peter Korsgaard
irq = platform_get_irq(pdev, 0);
> -if (irq == -ENXIO) {
> +if (i2c->flags & OCORES_FLAG_BROKEN_IRQ || irq == -ENXIO) {
Alternatively you can move it after the irq = platform_get_irq(pdev, 0)
line and just clear irq, E.G.:
irq = platform_get_irq(pdev, 0);
if (of_device_is_compatible(..)) {
i2c->flags |= OCORES_FLAG_BROKEN_IRQ;
irq = -ENXIO;
}
if (irq == -ENXIO) {
..
--
Bye, Peter Korsgaard
"sifive,fu540-c000-i2c"))
> Please let me know if this is okay.
Yes, that sounds sensible. Thanks.
--
Bye, Peter Korsgaard
her flags.
TYPE_SIFIVE_REV0 is also set for two compatibles:
{
.compatible = "sifive,fu540-c000-i2c",
.data = (void *)TYPE_SIFIVE_REV0,
},
{
.compatible = "sifive,i2c0",
.data = (void *)TYPE_SIFIVE_REV0,
},
Are both affected by this issue? if not, we will need to extend the code
to handle them differently.
Other than that, it looks OK to me.
--
Bye, Peter Korsgaard
>>>>> "Cristian" == Cristian Ciocaltea writes:
> Hi Peter,
> Thanks for the review!
> On Thu, Aug 27, 2020 at 08:44:40AM +0200, Peter Korsgaard wrote:
>> >>>>> "Cristian" == Cristian Ciocaltea
>> >>>&
>>>>> "Cristian" == Cristian Ciocaltea writes:
> Add a Device Tree for the RoseapplePi SBC.
> Signed-off-by: Cristian Ciocaltea
Reviewed-by: Peter Korsgaard
On a related note: There is now an owl-mmc driver for the s900. From a
quick look at th
>>>>> "Cristian" == Cristian Ciocaltea writes:
> The PPI interrupts for cortex-a9 were incorrectly specified, fix them.
> Fixes: fdfe7f4f9d85 ("ARM: dts: Add Actions Semi S500 and LeMaker Guitar")
> Signed-off-by: Cristian Ciocaltea
Reviewed-by: Peter Korsgaard
--
Bye, Peter Korsgaard
o this
> patch the IRQ controller behind this device, and its driver, can have
> different implementations (nested threads). For this reason, it is safer
> to use `request_any_context_irq()` to avoid errors at probe time.
> Signed-off-by: Federico Vaga
Reviewed-by: Peter Korsgaard
--
Bye, Peter Korsgaard
>>>>> "Jean" == Jean Delvare writes:
> On Tue, 2018-12-11 at 13:06 +0100, Peter Korsgaard wrote:
>> > > > > > "Peter" == Peter Korsgaard writes:
>>
>> Hi Jean,
>>
>> >> Look, you can imagine
>>>>> "Peter" == Peter Korsgaard writes:
Hi Jean,
>> Look, you can imagine that I was perfectly aware of what I was doing
>> when I made that change, and that I pondered the decision carefully at
>> that time. And my decision was that the change
LTS.
> I can't see how this is related with kernel 4.19 becoming LTS.
Only in the sense that that LTS kernels see wider use than non-LTS
kernels (E.G. I discovered this when moving from 4.14.x to 4.19.x).
> Look, you can imagine that I was perfectly aware of what I was doing
> when I made that change, and that I pondered the decision carefully at
> that time. And my decision was that the change should be made. As far
> as I'm concerned, this ship has sailed already, sorry.
Sorry, what is the perceived risk of reverting this change? Just the
minor inconsistency between the dmidecode and sysfs output? As stated
above, the RFC requires conforming parsers to handle upper case as well.
--
Bye, Peter Korsgaard
LTS.
> I can't see how this is related with kernel 4.19 becoming LTS.
Only in the sense that that LTS kernels see wider use than non-LTS
kernels (E.G. I discovered this when moving from 4.14.x to 4.19.x).
> Look, you can imagine that I was perfectly aware of what I was doing
> when I made that change, and that I pondered the decision carefully at
> that time. And my decision was that the change should be made. As far
> as I'm concerned, this ship has sailed already, sorry.
Sorry, what is the perceived risk of reverting this change? Just the
minor inconsistency between the dmidecode and sysfs output? As stated
above, the RFC requires conforming parsers to handle upper case as well.
--
Bye, Peter Korsgaard
>>>>> "Jean" == Jean Delvare writes:
> On Wed, 2018-12-05 at 22:13 +0100, Peter Korsgaard wrote:
>> This reverts commit 712ff25450bd01366301eef81c33e865d901e7b7.
>>
>> The output of dmi_save_uuid() is exposed to user space as
>> /sys/dev
>>>>> "Jean" == Jean Delvare writes:
> On Wed, 2018-12-05 at 22:13 +0100, Peter Korsgaard wrote:
>> This reverts commit 712ff25450bd01366301eef81c33e865d901e7b7.
>>
>> The output of dmi_save_uuid() is exposed to user space as
>> /sys/dev
>>>>> "Peter" == Peter Korsgaard writes:
> This reverts commit 712ff25450bd01366301eef81c33e865d901e7b7.
> The output of dmi_save_uuid() is exposed to user space as
> /sys/devices/virtual/dmi/id/*_uuid, so this breaks backwards compatibility,
> E.G. I
>>>>> "Peter" == Peter Korsgaard writes:
> This reverts commit 712ff25450bd01366301eef81c33e865d901e7b7.
> The output of dmi_save_uuid() is exposed to user space as
> /sys/devices/virtual/dmi/id/*_uuid, so this breaks backwards compatibility,
> E.G. I
for cryptsetup luksOpen.
As the change was purely cosmetical, revert it to fix such breakage.
Signed-off-by: Peter Korsgaard
---
drivers/firmware/dmi_scan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index
for cryptsetup luksOpen.
As the change was purely cosmetical, revert it to fix such breakage.
Signed-off-by: Peter Korsgaard
---
drivers/firmware/dmi_scan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index
>>>>> "Jerome" == Jerome Brunet writes:
> From: Neil Armstrong
> Add Libretech aml-s805x-ac board (aka 'La Frite') support
> Signed-off-by: Neil Armstrong
> Signed-off-by: Jerome Brunet
Reviewed-by: Peter Korsgaard
--
Bye, Peter Korsgaard
>>>>> "Jerome" == Jerome Brunet writes:
> From: Neil Armstrong
> Add Libretech aml-s805x-ac board (aka 'La Frite') support
> Signed-off-by: Neil Armstrong
> Signed-off-by: Jerome Brunet
Reviewed-by: Peter Korsgaard
--
Bye, Peter Korsgaard
* This is controlled by GPIOAO_9 we reserve this but
> + * claiming it as done bellow reset the board anyway
The 'bellow' typo is still here?
--
Bye, Peter Korsgaard
* This is controlled by GPIOAO_9 we reserve this but
> + * claiming it as done bellow reset the board anyway
The 'bellow' typo is still here?
--
Bye, Peter Korsgaard
* claiming it as done bellow reset the board anyway
s/bellow/below/
> + {
> +status = "okay";
> +pinctrl-0 = <_pins>;
> +pinctrl-names = "default";
> +
> +w25q32: spi-flash@0 {
> +#address-cells = <1>;
> +#size-cells = <1>;
> +compatible = "jedec,spi-nor";
> +reg = <0>;
> +spi-max-frequency = <300>;
Is this 3MHz a limitation of the flash, board layout or SPI controller?
--
Bye, Peter Korsgaard
* claiming it as done bellow reset the board anyway
s/bellow/below/
> + {
> +status = "okay";
> +pinctrl-0 = <_pins>;
> +pinctrl-names = "default";
> +
> +w25q32: spi-flash@0 {
> +#address-cells = <1>;
> +#size-cells = <1>;
> +compatible = "jedec,spi-nor";
> +reg = <0>;
> +spi-max-frequency = <300>;
Is this 3MHz a limitation of the flash, board layout or SPI controller?
--
Bye, Peter Korsgaard
For some use cases it is handy to use a different printk log level than the
default (info) for the messages written to ttyprintk, so add a Kconfig
option similar to what we have for default console loglevel.
Signed-off-by: Peter Korsgaard
---
Changes since v1:
- Leave [U] prefix in printk
For some use cases it is handy to use a different printk log level than the
default (info) for the messages written to ttyprintk, so add a Kconfig
option similar to what we have for default console loglevel.
Signed-off-by: Peter Korsgaard
---
Changes since v1:
- Leave [U] prefix in printk
in
> atomic context where we can't sleep at all.
Great! BTW I noticed that your sleep_min calculation looked odd:
int sleep_min = (8/i2c->bus_clock_khz) * 1000; /* us for 8bits
bus_clock_khz almost certainly will be bigger than 8 (E.G. likely
100KHz), so the above set sleep_min to 0. Please move the * 1000 before
the division.
--
Bye, Peter Korsgaard
in
> atomic context where we can't sleep at all.
Great! BTW I noticed that your sleep_min calculation looked odd:
int sleep_min = (8/i2c->bus_clock_khz) * 1000; /* us for 8bits
bus_clock_khz almost certainly will be bigger than 8 (E.G. likely
100KHz), so the above set sleep_min to 0. Please move the * 1000 before
the division.
--
Bye, Peter Korsgaard
>>>>> "Federico" == Federico Vaga writes:
Hi,
> I had another look at the HDL code and apparently my assumption was wrong,
> and
> STOP just do stop, and IACK is still necessary.
> So, yes, without try is better because we save an extra, useless,
>>>>> "Federico" == Federico Vaga writes:
Hi,
> I had another look at the HDL code and apparently my assumption was wrong,
> and
> STOP just do stop, and IACK is still necessary.
> So, yes, without try is better because we save an extra, useless,
the hardware is alive and what we read from
> oc_getreg() is correct. With this assumption, when there is a timeout this
> will happen:
> 1. STOP command (previous patch)
> 2. both TIP and BUSY will become zero at some point and we get out from the
> loop
> I can see now that there are cases when it may loop forever: for example if
> the device is broken and it does answer always with 0x: we should not
> break the host as well :)
> I can fix this.
Thanks!
--
Bye, Peter Korsgaard
the hardware is alive and what we read from
> oc_getreg() is correct. With this assumption, when there is a timeout this
> will happen:
> 1. STOP command (previous patch)
> 2. both TIP and BUSY will become zero at some point and we get out from the
> loop
> I can see now that there are cases when it may loop forever: for example if
> the device is broken and it does answer always with 0x: we should not
> break the host as well :)
> I can fix this.
Thanks!
--
Bye, Peter Korsgaard
For some use cases it is handy to use a different printk log level than the
default (info) for the messages written to ttyprintk, so add a Kconfig
option similar to what we have for default console loglevel.
Signed-off-by: Peter Korsgaard
---
Changes since v1:
- Leave [U] prefix in printk
For some use cases it is handy to use a different printk log level than the
default (info) for the messages written to ttyprintk, so add a Kconfig
option similar to what we have for default console loglevel.
Signed-off-by: Peter Korsgaard
---
Changes since v1:
- Leave [U] prefix in printk
);
> + oc_setreg(i2c, OCI2C_CONTROL, ctrl);
This looks unrelated to $SUBJECT
>
> prescale = (i2c->ip_clock_khz / (5 * i2c->bus_clock_khz)) - 1;
> prescale = clamp(prescale, 0, 0x);
> @@ -277,12 +332,16 @@ static int ocores_init(struct device *dev, struct
> ocores_i2c *i2c)
> return -EINVAL;
> }
>
> +
Here as well.
> @@ -538,6 +600,8 @@ static int ocores_i2c_remove(struct platform_device *pdev)
> {
> struct ocores_i2c *i2c = platform_get_drvdata(pdev);
>
> + flush_scheduled_work();
> +
Why not cancel_work_sync(>xfer_work)?
--
Bye, Peter Korsgaard
);
> + oc_setreg(i2c, OCI2C_CONTROL, ctrl);
This looks unrelated to $SUBJECT
>
> prescale = (i2c->ip_clock_khz / (5 * i2c->bus_clock_khz)) - 1;
> prescale = clamp(prescale, 0, 0x);
> @@ -277,12 +332,16 @@ static int ocores_init(struct device *dev, struct
> ocores_i2c *i2c)
> return -EINVAL;
> }
>
> +
Here as well.
> @@ -538,6 +600,8 @@ static int ocores_i2c_remove(struct platform_device *pdev)
> {
> struct ocores_i2c *i2c = platform_get_drvdata(pdev);
>
> + flush_scheduled_work();
> +
Why not cancel_work_sync(>xfer_work)?
--
Bye, Peter Korsgaard
function
> expects it to be read by the caller.
>
> Signed-off-by: Federico Vaga
Looks good.
Acked-by: Peter Korsgaard
--
Bye, Peter Korsgaard
function
> expects it to be read by the caller.
>
> Signed-off-by: Federico Vaga
Looks good.
Acked-by: Peter Korsgaard
--
Bye, Peter Korsgaard
l
don't quite understand this trylock logic. If we end up here with the
lock taken, then that must mean that we are on SMP system. We still
need to ack the interrupt, so just spinning until the other CPU
releases the lock seems more sensible?
--
Bye, Peter Korsgaard
l
don't quite understand this trylock logic. If we end up here with the
lock taken, then that must mean that we are on SMP system. We still
need to ack the interrupt, so just spinning until the other CPU
releases the lock seems more sensible?
--
Bye, Peter Korsgaard
For some use cases it is handy to use a different printk log level than the
default (info) for the messages written to ttyprintk, so add a Kconfig
option similar to what we have for default console loglevel.
Signed-off-by: Peter Korsgaard
---
Changes since v1:
- Leave [U] prefix in printk
For some use cases it is handy to use a different printk log level than the
default (info) for the messages written to ttyprintk, so add a Kconfig
option similar to what we have for default console loglevel.
Signed-off-by: Peter Korsgaard
---
Changes since v1:
- Leave [U] prefix in printk
>>>>> "Wolfram" == Wolfram Sang writes:
>> Thanks! I'll take a look at the patches now.
> Ping :)
I'm terribly sorry. I didn't manage to review before leaving on
travel. I'm back next week and then I'll review, OK?
--
Bye, Peter Korsgaard
>>>>> "Wolfram" == Wolfram Sang writes:
>> Thanks! I'll take a look at the patches now.
> Ping :)
I'm terribly sorry. I didn't manage to review before leaving on
travel. I'm back next week and then I'll review, OK?
--
Bye, Peter Korsgaard
On Fri, Sep 7, 2018 at 10:18 AM Peter Korsgaard wrote:
>
> For some use cases it is handy to use a different printk log level than the
> default (info) for the messages written to ttyprintk, so add a Kconfig
> option similar to what we have for default console loglevel.
>
> Si
On Fri, Sep 7, 2018 at 10:18 AM Peter Korsgaard wrote:
>
> For some use cases it is handy to use a different printk log level than the
> default (info) for the messages written to ttyprintk, so add a Kconfig
> option similar to what we have for default console loglevel.
>
> Si
For some use cases it is handy to use a different printk log level than the
default (info) for the messages written to ttyprintk, so add a Kconfig
option similar to what we have for default console loglevel.
Signed-off-by: Peter Korsgaard
---
Changes since v1:
- Leave [U] prefix in printk
For some use cases it is handy to use a different printk log level than the
default (info) for the messages written to ttyprintk, so add a Kconfig
option similar to what we have for default console loglevel.
Signed-off-by: Peter Korsgaard
---
Changes since v1:
- Leave [U] prefix in printk
>>>>> "Joe" == Joe Perches writes:
> On Fri, 2018-09-07 at 09:50 +0200, Peter Korsgaard wrote:
>> On Tue, Aug 21, 2018 at 7:28 PM Peter Korsgaard wrote:
>> >
>> > For some use cases it is handy to use a different printk log level t
>>>>> "Joe" == Joe Perches writes:
> On Fri, 2018-09-07 at 09:50 +0200, Peter Korsgaard wrote:
>> On Tue, Aug 21, 2018 at 7:28 PM Peter Korsgaard wrote:
>> >
>> > For some use cases it is handy to use a different printk log level t
On Tue, Aug 21, 2018 at 7:28 PM Peter Korsgaard wrote:
>
> For some use cases it is handy to use a different printk log level than the
> default (info) for the messages written to ttyprintk, so add a Kconfig
> option similar to what we have for default console loglevel.
Ping? Feedba
On Tue, Aug 21, 2018 at 7:28 PM Peter Korsgaard wrote:
>
> For some use cases it is handy to use a different printk log level than the
> default (info) for the messages written to ttyprintk, so add a Kconfig
> option similar to what we have for default console loglevel.
Ping? Feedba
it or not.
> Adding Peter to CC using his latest EMail address.
Thanks! I'll take a look at the patches now.
> Peter, you said you wanted to update MAINTAINERs with the new address?
Sorry, I forgot about it when I left on holidays. Will send now.
--
Bye, Peter Korsgaard
it or not.
> Adding Peter to CC using his latest EMail address.
Thanks! I'll take a look at the patches now.
> Peter, you said you wanted to update MAINTAINERs with the new address?
Sorry, I forgot about it when I left on holidays. Will send now.
--
Bye, Peter Korsgaard
For some use cases it is handy to use a different printk log level than the
default (info) for the messages written to ttyprintk, so add a Kconfig
option similar to what we have for default console loglevel.
Signed-off-by: Peter Korsgaard
---
drivers/char/Kconfig | 8
drivers/char
For some use cases it is handy to use a different printk log level than the
default (info) for the messages written to ttyprintk, so add a Kconfig
option similar to what we have for default console loglevel.
Signed-off-by: Peter Korsgaard
---
drivers/char/Kconfig | 8
drivers/char
t, thanks!
> @Peter: since the patch is trivial and nice to have in 4.17 already, I
> took the liberty to apply it right away. Hope this is fine with you.
Sorry for the slow response - Yes it is indeed.
--
Bye, Peter Korsgaard
t, thanks!
> @Peter: since the patch is trivial and nice to have in 4.17 already, I
> took the liberty to apply it right away. Hope this is fine with you.
Sorry for the slow response - Yes it is indeed.
--
Bye, Peter Korsgaard
>>>>> "WS" == Wolfram Sang <w...@the-dreams.de> writes:
WS> This header only contains platform_data. Move it to the proper directory.
WS> Signed-off-by: Wolfram Sang <w...@the-dreams.de>
Thanks,
Acked-by: Peter Korsgaard <peter.korsga...@ba
>>>>> "WS" == Wolfram Sang writes:
WS> This header only contains platform_data. Move it to the proper directory.
WS> Signed-off-by: Wolfram Sang
Thanks,
Acked-by: Peter Korsgaard
--
Bye, Peter Korsgaard
This message is subject to the following terms and co
>>>>> "Corentin" == Corentin Labbe <clabbe.montj...@gmail.com> writes:
> Instead of ading more ifthen login for adding a new mac_device_info
s/login/logic/
--
Bye, Peter Korsgaard
>>>>> "Corentin" == Corentin Labbe writes:
> Instead of ading more ifthen login for adding a new mac_device_info
s/login/logic/
--
Bye, Peter Korsgaard
reach till prompt for want of user space executables
>>
>> So far i have not come across a toolchain (or a way to create toolchain)
>> to create !MMU user space executables for Cortex-A.
> Now able to reach prompt using buildroot initramfs, Thanks to
> Peter Korsgaard for sug
ace executables
>>
>> So far i have not come across a toolchain (or a way to create toolchain)
>> to create !MMU user space executables for Cortex-A.
> Now able to reach prompt using buildroot initramfs, Thanks to
> Peter Korsgaard for suggesting the way to create
ne to carry the video signal all the way.
> Add a minimal driver for it that just claim the needed resources for the
> pipeline to operate properly.
> Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>
Acked-by: Peter Korsgaard <pe...@korsgaard.com>
--
Bye, Peter Korsgaard
the way.
> Add a minimal driver for it that just claim the needed resources for the
> pipeline to operate properly.
> Signed-off-by: Maxime Ripard
Acked-by: Peter Korsgaard
--
Bye, Peter Korsgaard
g.com/article/2010/04/content-adaptive-lcd-backlight-control
You spell out what DRC and SAT stands for in the driver source code,
perhaps it also makes sense to do it here?
Perhaps rewording it to something like this is clearer:
.. allows to dynamically adjust pixel brightness/contrast based on
histogram measurements for LCD content adaptive backlight control.
--
Bye, Peter Korsgaard
DRC and SAT stands for in the driver source code,
perhaps it also makes sense to do it here?
Perhaps rewording it to something like this is clearer:
.. allows to dynamically adjust pixel brightness/contrast based on
histogram measurements for LCD content adaptive backlight control.
--
Bye, Peter Korsgaard
>>>>> "Wolfram" == Wolfram Sang <wsa-...@sang-engineering.com> writes:
> The core will do this for us now.
> Signed-off-by: Wolfram Sang <wsa-...@sang-engineering.com>
> ---
> drivers/i2c/busses/i2c-ocores.c | 4 +---
For i2c-ocores.c
>>>>> "Wolfram" == Wolfram Sang writes:
> The core will do this for us now.
> Signed-off-by: Wolfram Sang
> ---
> drivers/i2c/busses/i2c-ocores.c | 4 +---
For i2c-ocores.c:
Acked-by: Peter Korsgaard
--
Bye, Peter Korsgaard
<khoroshi...@ispras.ru>
Acked-by: Peter Korsgaard <pe...@korsgaard.com>
--
Bye, Peter Korsgaard
>>>>> "Alexey" == Alexey Khoroshilov writes:
> clk_disable_unprepare() is missed on failure paths in ocores_i2c_probe().
> Found by Linux Driver Verification project (linuxtesting.org).
> Signed-off-by: Alexey Khoroshilov
Acked-by: Peter Korsgaard
--
Bye, Peter Korsgaard
8-bytes data to host per interrupt-interval */
> +dm_write_reg(dev, DM_USB_CTRL, USB_CTRL_EP3ACK);
Why would we want to do that instead of the current setup that afaik
only returns data when the link status changes?
--
Bye, Peter Korsgaard
l */
> +dm_write_reg(dev, DM_USB_CTRL, USB_CTRL_EP3ACK);
Why would we want to do that instead of the current setup that afaik
only returns data when the link status changes?
--
Bye, Peter Korsgaard
do this automatically without an explicit action from the user.
How common are these adapters without valid eeprom? What happens if the
eeprom content isn't fixed?
Do we need to reset the device once the eeprom is updated?
--
Bye, Peter Korsgaard
How common are these adapters without valid eeprom? What happens if the
eeprom content isn't fixed?
Do we need to reset the device once the eeprom is updated?
--
Bye, Peter Korsgaard
regmap = axp20x->regmap;
This could just use dev_get_regmap(pdev.dev->parent, NULL) instead of
fiddling in the parent driver data.
> +
> +ret = gpiochip_add(>chip);
> +if (ret) {
> + dev_err(>dev, "Failed to register GPIO chip\n");
> +return ret;
> +}
> +
> +dev_info(>dev, "AXP209 GPIO driver loaded\n");
Any reason to be so noisy?
--
Bye, Peter Korsgaard
d just use dev_get_regmap(pdev.dev->parent, NULL) instead of
fiddling in the parent driver data.
> +
> +ret = gpiochip_add(>chip);
> +if (ret) {
> + dev_err(>dev, "Failed to register GPIO chip\n");
> +return ret;
> +}
> +
> +dev_info(>dev, "AXP209 GPIO driver loaded\n");
Any reason to be so noisy?
--
Bye, Peter Korsgaard
d function dm9601_set_eeprom which tested good with ethtool
> utility.
Thanks for the patch. This sounds like 3 seperate changes, could you
please restructure it as 3 patches each doing one of the changes?
--
Bye, Peter Korsgaard
hich tested good with ethtool
> utility.
Thanks for the patch. This sounds like 3 seperate changes, could you
please restructure it as 3 patches each doing one of the changes?
--
Bye, Peter Korsgaard
le will do nothing.
To add to the confusion, the regulator part of the chip is actually
identical to act8865, so it could use the existing regulator driver /
compatible, except that it binds to the platform bus instead of i2c.
--
Bye, Peter Korsgaard
tely to that MFD) an OF table will do nothing.
To add to the confusion, the regulator part of the chip is actually
identical to act8865, so it could use the existing regulator driver /
compatible, except that it binds to the platform bus instead of i2c.
--
Bye, Peter Korsgaard
With that removed (and
the logic to devm_kzalloc it) you can add my:
Acked-by: Peter Korsgaard
> +static const struct mfd_cell act8945a_devs[] = {
> +{
> +.name = "act8945a-regulator",
> +.of_compatible = "active-
gt; +struct regmap *regmap;
> +};
You don't need this structure as you used devm. With that removed (and
the logic to devm_kzalloc it) you can add my:
Acked-by: Peter Korsgaard <pe...@korsgaard.com>
> +static const struct mfd_cell act8945a_devs[] = {
> +{
> +
break;
> +case 80:
> +value |= APCH_CFG_PRETIMO_80_MIN;
> +break;
> +case 0:
> +value |= APCH_CFG_PRETIMO_DISABLED;
> +break;
> +case 40:
> +default:
> +value |= APCH_CFG_PRETIMO_40_MIN;
> +break;
> +}
> +
> +switch (charger->tolal_time_out) {
> +case 4:
> +value |= APCH_CFG_TOTTIMO_4_HOUR;
> +break;
> +case 5:
> +value |= APCH_CFG_TOTTIMO_5_HOUR;
> +break;
> +case 0:
> +value |= APCH_CFG_TOTTIMO_DISABLED;
> +break;
> +case 3:
> +default:
> +value |= APCH_CFG_TOTTIMO_3_HOUR;
> +break;
> +}
> +
> +return regmap_write(regmap, ACT8945A_APCH_CFG, value);
> +}
> +
> +static int act8945a_charger_probe(struct platform_device *pdev)
> +{
> +struct act8945a_dev *act8945a_dev = dev_get_drvdata(pdev->dev.parent);
> +struct act8945a_charger *charger;
> +struct power_supply_config psy_cfg = {};
> +int ret;
> +
> +charger = devm_kzalloc(>dev, sizeof(*charger), GFP_KERNEL);
> +if (!charger)
> +return -ENOMEM;
> +
> +platform_set_drvdata(pdev, charger);
Never used, so you can drop this.
> +
> +charger->act8945a_dev = act8945a_dev;
Once again, why can't you just do something like:
charger->regmap = dev_get_regmap(pdev->dev.parent);
And drop this act8945_dev structure?
--
Bye, Peter Korsgaard
+case 40:
> +default:
> +value |= APCH_CFG_PRETIMO_40_MIN;
> +break;
> +}
> +
> +switch (charger->tolal_time_out) {
> +case 4:
> +value |= APCH_CFG_TOTTIMO_4_HOUR;
> +break;
> +case 5:
> +value |= APCH_CFG_TOTTIMO_5_HOUR;
> +break;
> +case 0:
> +value |= APCH_CFG_TOTTIMO_DISABLED;
> +break;
> +case 3:
> +default:
> +value |= APCH_CFG_TOTTIMO_3_HOUR;
> +break;
> +}
> +
> +return regmap_write(regmap, ACT8945A_APCH_CFG, value);
> +}
> +
> +static int act8945a_charger_probe(struct platform_device *pdev)
> +{
> +struct act8945a_dev *act8945a_dev = dev_get_drvdata(pdev->dev.parent);
> +struct act8945a_charger *charger;
> +struct power_supply_config psy_cfg = {};
> +int ret;
> +
> +charger = devm_kzalloc(>dev, sizeof(*charger), GFP_KERNEL);
> +if (!charger)
> +return -ENOMEM;
> +
> +platform_set_drvdata(pdev, charger);
Never used, so you can drop this.
> +
> +charger->act8945a_dev = act8945a_dev;
Once again, why can't you just do something like:
charger->regmap = dev_get_regmap(pdev->dev.parent);
And drop this act8945_dev structure?
--
Bye, Peter Korsgaard
ation isn't critical to get something running.
--
Bye, Peter Korsgaard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
, so it sounds like i2c
configuration isn't critical to get something running.
--
Bye, Peter Korsgaard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ad. It needs to be fixed as
>> > both memory blocks share the same address pointer.
>>
>> > I'll resend the series.
>>
>> But we're protected by the i2c bus lock, right? You do a single
>> i2c_transfer to read the serial number.
> Why the at24->
mory blocks share the same address pointer.
> I'll resend the series.
But we're protected by the i2c bus lock, right? You do a single
i2c_transfer to read the serial number.
--
Venlig hilsen,
Peter Korsgaard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> pointers).
As the serial number is available on a separate i2c address, wouldn't
it be simpler to handle these as special (read only) device variants and
instantiate E.G. a 24c64 (for the normal data) and a 24cs64 (for the
serial)?
--
Bye, Peter Korsgaard
--
To unsubscribe from this list:
in the serial read function - my bad. It needs to be fixed as
>> > both memory blocks share the same address pointer.
>>
>> > I'll resend the series.
>>
>> But we're protected by the i2c bus lock, right? You do a single
>> i2c_transfer to re
needs to be fixed as
> both memory blocks share the same address pointer.
> I'll resend the series.
But we're protected by the i2c bus lock, right? You do a single
i2c_transfer to read the serial number.
--
Venlig hilsen,
Peter Korsgaard
--
To unsubscribe from this list: send the line "
24cs02 chips (for both 16 and 8 bit address
> pointers).
As the serial number is available on a separate i2c address, wouldn't
it be simpler to handle these as special (read only) device variants and
instantiate E.G. a 24c64 (for the normal data) and a 24cs64 (for the
serial)?
--
Bye, Peter Korsgaard
--
t; +ret = PTR_ERR(dd->aclk);
It looks like it is the other way around. It should test
IS_ERR(dd->gclk) instead.
--
Bye, Peter Korsgaard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
if (IS_ERR(dd->aclk)) {
> -ret = PTR_ERR(dd->gclk);
> +ret = PTR_ERR(dd->aclk);
It looks like it is the other way around. It should test
IS_ERR(dd->gclk) instead.
--
Bye, Peter Korsgaard
--
To unsubscribe from this list: send the line "unsubscri
documented
> in the Documentation/devicetree/bindings/common-properties.txt
Ok, then it looks good to me.
--
Bye, Peter Korsgaard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at htt
> Changes v1->v2:
> - expand changelog with motivation for the change.
You should also document the big-endian property in
Documentation/devicetree/bindings/i2c/i2c-ocores.txt, otherwise it looks
good.
With that added:
Acked-by: Peter Korsgaard
--
Bye, Peter Korsgaard
--
To unsubscribe from t
and 'native-endian' are common properties documented
> in the Documentation/devicetree/bindings/common-properties.txt
Ok, then it looks good to me.
--
Bye, Peter Korsgaard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
M
1 - 100 of 271 matches
Mail list logo
