* Re: Multiple undefined configuration options are dependent in Kconfig under the v6.3-rc4 drivers directory
2023-04-14 8:18 0% ` Jiaxun Yang
@ 2023-04-21 13:19 0% ` Serge Semin
0 siblings, 0 replies; 15+ results
From: Serge Semin @ 2023-04-21 13:19 UTC (permalink / raw)
To: Jiaxun Yang; +Cc: linux-kernel, linux-mips
On Fri, Apr 14, 2023 at 09:18:20AM +0100, Jiaxun Yang wrote:
>
>
> > 2023年4月11日 00:40，Serge Semin <fancer.lancer@gmail.com> 写道：
> >
> > On Thu, Mar 30, 2023 at 07:34:58AM +0900, Damien Le Moal wrote:
> >> On 3/29/23 16:52, 孙滢 wrote:
> >>> It has been discovered that the following configuration options are undefined in the current latest version, v6.3-rc4, yet they are being relied upon by other configuration options in multiple Kconfig files:
> >>>
> >>> MIPS_BAIKAL_T1 is undefined, used as a 'depends on' condition in multiple files such as drivers/ata/Kconfig, drivers/hwmon/Kconfig, drivers/bus/Kconfig, and drivers/memory/Kconfig.
> >>> MFD_MAX597X is undefined, used as a 'depends on' condition in Kconfig file drivers/regulator/Kconfig.
> >>> MFD_SM5703 is undefined, used as a 'depends on' condition in Kconfig file drivers/regulator/Kconfig.
> >>> ARCH_THUNDERBAY is undefined, used as a 'depends on' condition in Kconfig files drivers/pinctrl/Kconfig and drivers/phy/intel/Kconfig.
> >>> ARCH_BCM4908 is undefined, used as a 'depends on' condition in Kconfig file drivers/leds/blink/Kconfig.
> >>> MFD_TN48M_CPLD is undefined, used as a 'depends on' condition in Kconfig files drivers/gpio/Kconfig and drivers/reset/Kconfig.
> >>> USB_HSIC_USB3613 is undefined, used as a 'depends on' condition in drivers/staging/greybus/Kconfig and drivers/staging/greybus/arche-platform.c.
> >
> > Please, don't drop the MIPS_BAIKAL_T1 config. It will be defined and
> > thus utilized after I submit the SoC CSP support to the MIPS arch.
>
> Hi Serge,
>
> Is there any special support at MIPS arch level required by Baikal T1?
>
> I think MIPS32R5 generic kernel should fit your purpose? You can easily add some “workaround”
> under generic kernel framework as well.
Alas there are multiple configs specific to our chip. So the MIPS
generic sub-module won't workout our needs at the current state. I'll
have a better look at it when time comes (whether it's possible to fix
it up somehow) but meanwhile it's better to retain the MIPS_BAIKAL_T1
config in the drivers.
-Serge(y)
>
> Thanks
> Jiaxun
>
>
>
>
^ permalink raw reply [relevance 0%]
* Re: Multiple undefined configuration options are dependent in Kconfig under the v6.3-rc4 drivers directory
2023-04-10 23:40 0% ` Serge Semin
(?)
@ 2023-04-14 8:18 0% ` Jiaxun Yang
2023-04-21 13:19 0% ` Serge Semin
-1 siblings, 1 reply; 15+ results
From: Jiaxun Yang @ 2023-04-14 8:18 UTC (permalink / raw)
To: Serge Semin; +Cc: linux-kernel, linux-mips
> 2023年4月11日 00:40，Serge Semin <fancer.lancer@gmail.com> 写道：
>
> On Thu, Mar 30, 2023 at 07:34:58AM +0900, Damien Le Moal wrote:
>> On 3/29/23 16:52, 孙滢 wrote:
>>> It has been discovered that the following configuration options are undefined in the current latest version, v6.3-rc4, yet they are being relied upon by other configuration options in multiple Kconfig files:
>>>
>>> MIPS_BAIKAL_T1 is undefined, used as a 'depends on' condition in multiple files such as drivers/ata/Kconfig, drivers/hwmon/Kconfig, drivers/bus/Kconfig, and drivers/memory/Kconfig.
>>> MFD_MAX597X is undefined, used as a 'depends on' condition in Kconfig file drivers/regulator/Kconfig.
>>> MFD_SM5703 is undefined, used as a 'depends on' condition in Kconfig file drivers/regulator/Kconfig.
>>> ARCH_THUNDERBAY is undefined, used as a 'depends on' condition in Kconfig files drivers/pinctrl/Kconfig and drivers/phy/intel/Kconfig.
>>> ARCH_BCM4908 is undefined, used as a 'depends on' condition in Kconfig file drivers/leds/blink/Kconfig.
>>> MFD_TN48M_CPLD is undefined, used as a 'depends on' condition in Kconfig files drivers/gpio/Kconfig and drivers/reset/Kconfig.
>>> USB_HSIC_USB3613 is undefined, used as a 'depends on' condition in drivers/staging/greybus/Kconfig and drivers/staging/greybus/arche-platform.c.
>
> Please, don't drop the MIPS_BAIKAL_T1 config. It will be defined and
> thus utilized after I submit the SoC CSP support to the MIPS arch.
Hi Serge,
Is there any special support at MIPS arch level required by Baikal T1?
I think MIPS32R5 generic kernel should fit your purpose? You can easily add some “workaround”
under generic kernel framework as well.
Thanks
Jiaxun
^ permalink raw reply [relevance 0%]
* Re: Multiple undefined configuration options are dependent in Kconfig under the v6.3-rc4 drivers directory
2023-03-29 22:34 0% ` Damien Le Moal
@ 2023-04-10 23:40 0% ` Serge Semin
-1 siblings, 0 replies; 15+ results
From: Serge Semin @ 2023-04-10 23:40 UTC (permalink / raw)
To: Damien Le Moal, sunying
Cc: Damien Le Moal, linux-ide, linux-kernel, greybus-dev, Linux ARM,
linux-mips
On Thu, Mar 30, 2023 at 07:34:58AM +0900, Damien Le Moal wrote:
> On 3/29/23 16:52, 孙滢 wrote:
> > It has been discovered that the following configuration options are undefined in the current latest version, v6.3-rc4, yet they are being relied upon by other configuration options in multiple Kconfig files:
> >
> > MIPS_BAIKAL_T1 is undefined, used as a 'depends on' condition in multiple files such as drivers/ata/Kconfig, drivers/hwmon/Kconfig, drivers/bus/Kconfig, and drivers/memory/Kconfig.
> > MFD_MAX597X is undefined, used as a 'depends on' condition in Kconfig file drivers/regulator/Kconfig.
> > MFD_SM5703 is undefined, used as a 'depends on' condition in Kconfig file drivers/regulator/Kconfig.
> > ARCH_THUNDERBAY is undefined, used as a 'depends on' condition in Kconfig files drivers/pinctrl/Kconfig and drivers/phy/intel/Kconfig.
> > ARCH_BCM4908 is undefined, used as a 'depends on' condition in Kconfig file drivers/leds/blink/Kconfig.
> > MFD_TN48M_CPLD is undefined, used as a 'depends on' condition in Kconfig files drivers/gpio/Kconfig and drivers/reset/Kconfig.
> > USB_HSIC_USB3613 is undefined, used as a 'depends on' condition in drivers/staging/greybus/Kconfig and drivers/staging/greybus/arche-platform.c.
Please, don't drop the MIPS_BAIKAL_T1 config. It will be defined and
thus utilized after I submit the SoC CSP support to the MIPS arch.
-Serge(y)
> >
> > If these 7 configuration options are deprecated, it is recommended to remove the dependencies on them in the Kconfig files.
> > If they are still useful, it is recommended to define them.
>
> + linux-arm & linux-mips
>
> What about you send patches to fix this ?
>
> >
> >
> > Best regards,
> > Ying Sun
> > Pengpeng Hou
> > Yanjie Ren
>
> --
> Damien Le Moal
> Western Digital Research
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [relevance 0%]
* Re: Multiple undefined configuration options are dependent in Kconfig under the v6.3-rc4 drivers directory
@ 2023-04-10 23:40 0% ` Serge Semin
0 siblings, 0 replies; 15+ results
From: Serge Semin @ 2023-04-10 23:40 UTC (permalink / raw)
To: Damien Le Moal, sunying
Cc: Damien Le Moal, linux-ide, linux-kernel, greybus-dev, Linux ARM,
linux-mips
On Thu, Mar 30, 2023 at 07:34:58AM +0900, Damien Le Moal wrote:
> On 3/29/23 16:52, 孙滢 wrote:
> > It has been discovered that the following configuration options are undefined in the current latest version, v6.3-rc4, yet they are being relied upon by other configuration options in multiple Kconfig files:
> >
> > MIPS_BAIKAL_T1 is undefined, used as a 'depends on' condition in multiple files such as drivers/ata/Kconfig, drivers/hwmon/Kconfig, drivers/bus/Kconfig, and drivers/memory/Kconfig.
> > MFD_MAX597X is undefined, used as a 'depends on' condition in Kconfig file drivers/regulator/Kconfig.
> > MFD_SM5703 is undefined, used as a 'depends on' condition in Kconfig file drivers/regulator/Kconfig.
> > ARCH_THUNDERBAY is undefined, used as a 'depends on' condition in Kconfig files drivers/pinctrl/Kconfig and drivers/phy/intel/Kconfig.
> > ARCH_BCM4908 is undefined, used as a 'depends on' condition in Kconfig file drivers/leds/blink/Kconfig.
> > MFD_TN48M_CPLD is undefined, used as a 'depends on' condition in Kconfig files drivers/gpio/Kconfig and drivers/reset/Kconfig.
> > USB_HSIC_USB3613 is undefined, used as a 'depends on' condition in drivers/staging/greybus/Kconfig and drivers/staging/greybus/arche-platform.c.
Please, don't drop the MIPS_BAIKAL_T1 config. It will be defined and
thus utilized after I submit the SoC CSP support to the MIPS arch.
-Serge(y)
> >
> > If these 7 configuration options are deprecated, it is recommended to remove the dependencies on them in the Kconfig files.
> > If they are still useful, it is recommended to define them.
>
> + linux-arm & linux-mips
>
> What about you send patches to fix this ?
>
> >
> >
> > Best regards,
> > Ying Sun
> > Pengpeng Hou
> > Yanjie Ren
>
> --
> Damien Le Moal
> Western Digital Research
>
^ permalink raw reply [relevance 0%]
* Re: Multiple undefined configuration options are dependent in Kconfig under the v6.3-rc4 drivers directory
2023-03-29 7:52 6% Multiple undefined configuration options are dependent in Kconfig under the v6.3-rc4 drivers directory 孙滢
@ 2023-03-29 22:34 0% ` Damien Le Moal
0 siblings, 0 replies; 15+ results
From: Damien Le Moal @ 2023-03-29 22:34 UTC (permalink / raw)
To: 孙滢,
linux-ide, linux-kernel, greybus-dev, Linux ARM, linux-mips
On 3/29/23 16:52, 孙滢 wrote:
> It has been discovered that the following configuration options are undefined in the current latest version, v6.3-rc4, yet they are being relied upon by other configuration options in multiple Kconfig files:
>
> MIPS_BAIKAL_T1 is undefined, used as a 'depends on' condition in multiple files such as drivers/ata/Kconfig, drivers/hwmon/Kconfig, drivers/bus/Kconfig, and drivers/memory/Kconfig.
> MFD_MAX597X is undefined, used as a 'depends on' condition in Kconfig file drivers/regulator/Kconfig.
> MFD_SM5703 is undefined, used as a 'depends on' condition in Kconfig file drivers/regulator/Kconfig.
> ARCH_THUNDERBAY is undefined, used as a 'depends on' condition in Kconfig files drivers/pinctrl/Kconfig and drivers/phy/intel/Kconfig.
> ARCH_BCM4908 is undefined, used as a 'depends on' condition in Kconfig file drivers/leds/blink/Kconfig.
> MFD_TN48M_CPLD is undefined, used as a 'depends on' condition in Kconfig files drivers/gpio/Kconfig and drivers/reset/Kconfig.
> USB_HSIC_USB3613 is undefined, used as a 'depends on' condition in drivers/staging/greybus/Kconfig and drivers/staging/greybus/arche-platform.c.
>
> If these 7 configuration options are deprecated, it is recommended to remove the dependencies on them in the Kconfig files.
> If they are still useful, it is recommended to define them.
+ linux-arm & linux-mips
What about you send patches to fix this ?
>
>
> Best regards,
> Ying Sun
> Pengpeng Hou
> Yanjie Ren
--
Damien Le Moal
Western Digital Research
^ permalink raw reply [relevance 0%]
* Re: Multiple undefined configuration options are dependent in Kconfig under the v6.3-rc4 drivers directory
@ 2023-03-29 22:34 0% ` Damien Le Moal
0 siblings, 0 replies; 15+ results
From: Damien Le Moal @ 2023-03-29 22:34 UTC (permalink / raw)
To: 孙滢,
linux-ide, linux-kernel, greybus-dev, Linux ARM, linux-mips
On 3/29/23 16:52, 孙滢 wrote:
> It has been discovered that the following configuration options are undefined in the current latest version, v6.3-rc4, yet they are being relied upon by other configuration options in multiple Kconfig files:
>
> MIPS_BAIKAL_T1 is undefined, used as a 'depends on' condition in multiple files such as drivers/ata/Kconfig, drivers/hwmon/Kconfig, drivers/bus/Kconfig, and drivers/memory/Kconfig.
> MFD_MAX597X is undefined, used as a 'depends on' condition in Kconfig file drivers/regulator/Kconfig.
> MFD_SM5703 is undefined, used as a 'depends on' condition in Kconfig file drivers/regulator/Kconfig.
> ARCH_THUNDERBAY is undefined, used as a 'depends on' condition in Kconfig files drivers/pinctrl/Kconfig and drivers/phy/intel/Kconfig.
> ARCH_BCM4908 is undefined, used as a 'depends on' condition in Kconfig file drivers/leds/blink/Kconfig.
> MFD_TN48M_CPLD is undefined, used as a 'depends on' condition in Kconfig files drivers/gpio/Kconfig and drivers/reset/Kconfig.
> USB_HSIC_USB3613 is undefined, used as a 'depends on' condition in drivers/staging/greybus/Kconfig and drivers/staging/greybus/arche-platform.c.
>
> If these 7 configuration options are deprecated, it is recommended to remove the dependencies on them in the Kconfig files.
> If they are still useful, it is recommended to define them.
+ linux-arm & linux-mips
What about you send patches to fix this ?
>
>
> Best regards,
> Ying Sun
> Pengpeng Hou
> Yanjie Ren
--
Damien Le Moal
Western Digital Research
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [relevance 0%]
* Multiple undefined configuration options are dependent in Kconfig under the v6.3-rc4 drivers directory
@ 2023-03-29 7:52 6% 孙滢
2023-03-29 22:34 0% ` Damien Le Moal
0 siblings, 1 reply; 15+ results
From: 孙滢 @ 2023-03-29 7:52 UTC (permalink / raw)
To: linux-ide, linux-kernel, greybus-dev
It has been discovered that the following configuration options are undefined in the current latest version, v6.3-rc4, yet they are being relied upon by other configuration options in multiple Kconfig files:
MIPS_BAIKAL_T1 is undefined, used as a 'depends on' condition in multiple files such as drivers/ata/Kconfig, drivers/hwmon/Kconfig, drivers/bus/Kconfig, and drivers/memory/Kconfig.
MFD_MAX597X is undefined, used as a 'depends on' condition in Kconfig file drivers/regulator/Kconfig.
MFD_SM5703 is undefined, used as a 'depends on' condition in Kconfig file drivers/regulator/Kconfig.
ARCH_THUNDERBAY is undefined, used as a 'depends on' condition in Kconfig files drivers/pinctrl/Kconfig and drivers/phy/intel/Kconfig.
ARCH_BCM4908 is undefined, used as a 'depends on' condition in Kconfig file drivers/leds/blink/Kconfig.
MFD_TN48M_CPLD is undefined, used as a 'depends on' condition in Kconfig files drivers/gpio/Kconfig and drivers/reset/Kconfig.
USB_HSIC_USB3613 is undefined, used as a 'depends on' condition in drivers/staging/greybus/Kconfig and drivers/staging/greybus/arche-platform.c.
If these 7 configuration options are deprecated, it is recommended to remove the dependencies on them in the Kconfig files.
If they are still useful, it is recommended to define them.
Best regards,
Ying Sun
Pengpeng Hou
Yanjie Ren
^ permalink raw reply [relevance 6%]
* Re: [PATCH] staging: greybus: fix exceeds line length
@ 2023-03-13 4:30 7% ` Lukas Bulwahn
0 siblings, 0 replies; 15+ results
From: Lukas Bulwahn @ 2023-03-13 4:30 UTC (permalink / raw)
To: Dan Carpenter
Cc: Khadija Kamran, outreachy, Vaibhav Hiremath, Johan Hovold,
Alex Elder, Greg Kroah-Hartman, greybus-dev, linux-staging,
linux-kernel
On Fri, Mar 10, 2023 at 8:40 PM Dan Carpenter <error27@gmail.com> wrote:
>
> On Fri, Mar 10, 2023 at 10:09:47PM +0500, Khadija Kamran wrote:
> > Length of line 182 exceeds 100 columns in file
> > drivers/staging/grebus/arche-platform.c, fix by removing tabs from the
> > line.
> >
> > Signed-off-by: Khadija Kamran <kamrankhadijadj@gmail.com>
> > ---
> > drivers/staging/greybus/arche-platform.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/greybus/arche-platform.c b/drivers/staging/greybus/arche-platform.c
> > index fcbd5f71eff2..0f0fbc263f8a 100644
> > --- a/drivers/staging/greybus/arche-platform.c
> > +++ b/drivers/staging/greybus/arche-platform.c
> > @@ -179,7 +179,7 @@ static irqreturn_t arche_platform_wd_irq(int irq, void *devid)
> > if (arche_pdata->wake_detect_state !=
> > WD_STATE_COLDBOOT_START) {
> > arche_platform_set_wake_detect_state(arche_pdata,
> > - WD_STATE_COLDBOOT_TRIG);
> > + WD_STATE_COLDBOOT_TRIG);
>
> The original line was done deliberately so that it lines up. If we
> apply your patch and re-run checkpatch -f on the file then it has a new
> warning:
>
> CHECK: Alignment should match open parenthesis
> #182: FILE: drivers/staging/greybus/arche-platform.c:182:
> + arche_platform_set_wake_detect_state(arche_pdata,
> + WD_STATE_COLDBOOT_TRIG);
>
> Always try to think about the bigger picture. Why did the original
> author do it that way? The change makes checkpatch happy, but does it
> make the code more readable? Is there a more important readability
> improvement to be done here?
>
> For example, you could re-arrange the if statements like this and pull
> everything in a few tabs. Don't necessarily do that. Just think about
> doing it. I write quite a few cleanup patches that I don't send because
> the next day I just decide it's not worth it.
>
> When I look at this file, the style is not bad at all. But at the start
> of the file there is #if IS_ENABLED(CONFIG_USB_HSIC_USB3613). What is
> that? The CONFIG doesn't exist and the header doesn't exits. Probably
> it can be deleted.
>
> But that raises a new question. Lukas Bulwahn is always looking for
> CONFIG_ entries which don't exist. I would have expected him to find
> this already.
>
True, and my (private) random linux notes of the checkkconfigsymbols
effort on this config states:
USB_HSIC_USB3613: Reported and maintenance of dead code is fine for
staging maintainer
So, I did report it, and a quick search on lore.kernel.org
(https://lore.kernel.org/all/?q=USB_HSIC_USB3613) will give us some
more insight and refresh Greg's and my memory:
I reported the issue here:
https://lore.kernel.org/all/CAKXUXMym0M1UNuNGUVpFr2yUwOwjkZ_sQpCD0jC8YB+hs=j-bA@mail.gmail.com/
And Greg responded:
"... It's a good example driver for those wanting to create a greybus
host controller driver so it's nice to have in the tree..."
So, even though the code is dead, it is a nice example of some driver
code. So, we keep it.
> Anyway, we can write our own scripts to make a list of stuff inside
> IS_ENABLED():
>
> git grep IS_ENABLED | \
> perl -ne 'if (/IS_ENABLED\((.+?)\)/){ print "$1\n"}' | \
> sort -u | tee CONFIG_list
>
> Then we can go through the CONFIG_list file and see which other stuff
> doesn't exist.
>
> for i in $(grep ^CONFIG CONFIG_list | cut -d '_' -f 2-) ; do \
> grep -q -w "config $i$" $(find -name Kconfig) || echo $i ; \
> done | tee CONFIG_not_found
>
> I have never done this before so I don't know what you'll find. But
> everywhere you look if you just look closer then it raises questions
> which raise more questions. So it's interesting to explore. Anyway,
> look closely at each line in the file and follow the rabbit holes until
> you find something interesting to work on.
>
@Dan, Thanks for pointing out my clean-up activity here!
Yes, I agree with Dan. That is certainly an interesting task to
explore. If you search the mailing list, you will find another bash
script of similar length that Joe Perches used a few years back. I
personally use the script ./scripts/checkkconfigsymbols.py. They may
differ a bit on what they report, but I fear at this point, most of
its reports are false positives. I have looked at all of them, I am
checking the new ones introduced, and sending out patches to clean up
stuff. There are a few on my todo list, like cleaning up the
definition of CONFIG_CAAM_QI. If you want to assist, please let me
know. I can certainly give you a few things that are at least worth a
deeper investigation and maybe also some clean up.
Lukas
> regards,
> dan carpenter
>
> diff --git a/drivers/staging/greybus/arche-platform.c b/drivers/staging/greybus/arche-platform.c
> index fcbd5f71eff2..2d9e0c41b5e3 100644
> --- a/drivers/staging/greybus/arche-platform.c
> +++ b/drivers/staging/greybus/arche-platform.c
> @@ -165,43 +165,39 @@ static irqreturn_t arche_platform_wd_irq(int irq, void *devid)
> * 30msec, then standby boot sequence is initiated, which is not
> * supported/implemented as of now. So ignore it.
> */
> - if (arche_pdata->wake_detect_state == WD_STATE_BOOT_INIT) {
> - if (time_before(jiffies,
> - arche_pdata->wake_detect_start +
> - msecs_to_jiffies(WD_COLDBOOT_PULSE_WIDTH_MS))) {
> - arche_platform_set_wake_detect_state(arche_pdata,
> - WD_STATE_IDLE);
> - } else {
> - /*
> - * Check we are not in middle of irq thread
> - * already
> - */
> - if (arche_pdata->wake_detect_state !=
> - WD_STATE_COLDBOOT_START) {
> - arche_platform_set_wake_detect_state(arche_pdata,
> - WD_STATE_COLDBOOT_TRIG);
> - spin_unlock_irqrestore(&arche_pdata->wake_lock,
> - flags);
> - return IRQ_WAKE_THREAD;
> - }
> - }
> - }
> - } else {
> - /* wake/detect falling */
> - if (arche_pdata->wake_detect_state == WD_STATE_IDLE) {
> - arche_pdata->wake_detect_start = jiffies;
> + if (arche_pdata->wake_detect_state != WD_STATE_BOOT_INIT)
> + goto out_unlock;
> +
> + if (time_before(jiffies,
> + arche_pdata->wake_detect_start +
> + msecs_to_jiffies(WD_COLDBOOT_PULSE_WIDTH_MS))) {
> + arche_platform_set_wake_detect_state(arche_pdata,
> + WD_STATE_IDLE);
> + } else if (arche_pdata->wake_detect_state != WD_STATE_COLDBOOT_START) {
> /*
> - * In the beginning, when wake/detect goes low
> - * (first time), we assume it is meant for coldboot
> - * and set the flag. If wake/detect line stays low
> - * beyond 30msec, then it is coldboot else fallback
> - * to standby boot.
> + * Check we are not in middle of irq thread
> + * already
> */
> arche_platform_set_wake_detect_state(arche_pdata,
> - WD_STATE_BOOT_INIT);
> + WD_STATE_COLDBOOT_TRIG);
> + spin_unlock_irqrestore(&arche_pdata->wake_lock, flags);
> + return IRQ_WAKE_THREAD;
> }
> + } else if (arche_pdata->wake_detect_state == WD_STATE_IDLE) {
> + /* wake/detect falling */
> + arche_pdata->wake_detect_start = jiffies;
> + /*
> + * In the beginning, when wake/detect goes low
> + * (first time), we assume it is meant for coldboot
> + * and set the flag. If wake/detect line stays low
> + * beyond 30msec, then it is coldboot else fallback
> + * to standby boot.
> + */
> + arche_platform_set_wake_detect_state(arche_pdata,
> + WD_STATE_BOOT_INIT);
> }
>
> +out_unlock:
> spin_unlock_irqrestore(&arche_pdata->wake_lock, flags);
>
> return IRQ_HANDLED;
^ permalink raw reply [relevance 7%]
* Re: Addition of config USB_HSIC_USB3613 soon?
2021-12-22 9:58 6% ` Greg Kroah-Hartman
@ 2021-12-22 10:10 6% ` Lukas Bulwahn
0 siblings, 0 replies; 15+ results
From: Lukas Bulwahn @ 2021-12-22 10:10 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Vaibhav Hiremath, Johan Hovold, Alex Elder, greybus-dev,
Linux Kernel Mailing List, linux-staging
On Wed, Dec 22, 2021 at 10:58 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Wed, Dec 22, 2021 at 10:54:41AM +0100, Lukas Bulwahn wrote:
> > Dear Vaibhav, dear Johan, dear Alex, dear Greg,
> >
> > I have seen that the greybus arche driver has been under heavy
> > development in 2016 and 2017 with some further clean-up in 2019.
> >
> > However, so far, the config GREYBUS_ARCHE for this driver still
> > depends on the out-of-tree config USB_HSIC_USB3613, with a proper
> > exception made for compile testing (with COMPILE_TEST).
> >
> > Will this USB_HSIC_USB3613 config and driver still be added in the
> > mainline kernel in the near future, so that the config dependencies
> > are consistent in mainline?
>
> Do you have this hardware? If so, we can add the driver, but given that
> I did not think the chip ever actually shipped, it didn't make much
> sense.
>
> > Or, are the further out-of-tree additions still maintained for the
> > current kernel and will stay out of tree? Is this arche driver not
> > needed anymore and can be dropped?
>
> Do you want to drop it as it is causing problems for you? It's a good
> example driver for those wanting to create a greybus host controller
> driver so it's nice to have in the tree, unless you have a different one
> that should be merged instead?
>
Greg, I just stumbled over this code due to some janitorial workwith
./scripts/checkkconfigsymbols.py in the kernel repository and wondered
if it is worth keeping this in the kernel tree. I do not have the
hardware, nor do I need it and the driver code to it.
Of course, the repository is full of other dead code*... so, if you
know the current state of this driver, it just remains in staging, and
is actually a good example for educational purposes, we are all fine
:)
*... This is not a complaint, but my task description for me as kernel
janitor to submit clean-up patches for the various places of the dead
code.
Thanks for your quick response,
Lukas
^ permalink raw reply [relevance 6%]
* Re: Addition of config USB_HSIC_USB3613 soon?
2021-12-22 9:54 14% Addition of config USB_HSIC_USB3613 soon? Lukas Bulwahn
@ 2021-12-22 9:58 6% ` Greg Kroah-Hartman
2021-12-22 10:10 6% ` Lukas Bulwahn
0 siblings, 1 reply; 15+ results
From: Greg Kroah-Hartman @ 2021-12-22 9:58 UTC (permalink / raw)
To: Lukas Bulwahn
Cc: Vaibhav Hiremath, Johan Hovold, Alex Elder, greybus-dev,
Linux Kernel Mailing List, linux-staging
On Wed, Dec 22, 2021 at 10:54:41AM +0100, Lukas Bulwahn wrote:
> Dear Vaibhav, dear Johan, dear Alex, dear Greg,
>
> I have seen that the greybus arche driver has been under heavy
> development in 2016 and 2017 with some further clean-up in 2019.
>
> However, so far, the config GREYBUS_ARCHE for this driver still
> depends on the out-of-tree config USB_HSIC_USB3613, with a proper
> exception made for compile testing (with COMPILE_TEST).
>
> Will this USB_HSIC_USB3613 config and driver still be added in the
> mainline kernel in the near future, so that the config dependencies
> are consistent in mainline?
Do you have this hardware? If so, we can add the driver, but given that
I did not think the chip ever actually shipped, it didn't make much
sense.
> Or, are the further out-of-tree additions still maintained for the
> current kernel and will stay out of tree? Is this arche driver not
> needed anymore and can be dropped?
Do you want to drop it as it is causing problems for you? It's a good
example driver for those wanting to create a greybus host controller
driver so it's nice to have in the tree, unless you have a different one
that should be merged instead?
thanks,
greg k-h
^ permalink raw reply [relevance 6%]
* Addition of config USB_HSIC_USB3613 soon?
@ 2021-12-22 9:54 14% Lukas Bulwahn
2021-12-22 9:58 6% ` Greg Kroah-Hartman
0 siblings, 1 reply; 15+ results
From: Lukas Bulwahn @ 2021-12-22 9:54 UTC (permalink / raw)
To: Vaibhav Hiremath, Johan Hovold, Alex Elder, Greg Kroah-Hartman,
greybus-dev
Cc: Linux Kernel Mailing List, linux-staging
Dear Vaibhav, dear Johan, dear Alex, dear Greg,
I have seen that the greybus arche driver has been under heavy
development in 2016 and 2017 with some further clean-up in 2019.
However, so far, the config GREYBUS_ARCHE for this driver still
depends on the out-of-tree config USB_HSIC_USB3613, with a proper
exception made for compile testing (with COMPILE_TEST).
Will this USB_HSIC_USB3613 config and driver still be added in the
mainline kernel in the near future, so that the config dependencies
are consistent in mainline?
Or, are the further out-of-tree additions still maintained for the
current kernel and will stay out of tree? Is this arche driver not
needed anymore and can be dropped?
Best regards,
Lukas
^ permalink raw reply [relevance 14%]
* [PATCH] staging: greybus: use help instead of ---help--- in Kconfig
@ 2019-04-20 9:21 4% MosesChristopher
0 siblings, 0 replies; 15+ results
From: MosesChristopher @ 2019-04-20 9:21 UTC (permalink / raw)
To: johan, elder, gregkh; +Cc: greybus-dev, devel, linux-kernel, Moses Christopher
From: Moses Christopher <moseschristopherb@gmail.com>
- Resolve the following warning from the Kconfig,
"WARNING: prefer 'help' over '---help---' for new help texts"
Signed-off-by: Moses Christopher <moseschristopherb@gmail.com>
---
drivers/staging/greybus/Kconfig | 44 ++++++++++++++++++++---------------------
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/staging/greybus/Kconfig b/drivers/staging/greybus/Kconfig
index b571e4e8060b..2f5061b565a6 100644
--- a/drivers/staging/greybus/Kconfig
+++ b/drivers/staging/greybus/Kconfig
@@ -1,7 +1,7 @@
menuconfig GREYBUS
tristate "Greybus support"
depends on SYSFS
- ---help---
+ help
This option enables the Greybus driver core. Greybus is an
hardware protocol that was designed to provide Unipro with a
sane application layer. It was originally designed for the
@@ -19,7 +19,7 @@ if GREYBUS
config GREYBUS_ES2
tristate "Greybus ES3 USB host controller"
depends on USB
- ---help---
+ help
Select this option if you have a Toshiba ES3 USB device that
acts as a Greybus "host controller". This device is a bridge
from a USB device to a Unipro network.
@@ -30,7 +30,7 @@ config GREYBUS_ES2
config GREYBUS_AUDIO
tristate "Greybus Audio Class driver"
depends on SOUND
- ---help---
+ help
Select this option if you have a device that follows the
Greybus Audio Class specification.
@@ -39,7 +39,7 @@ config GREYBUS_AUDIO
config GREYBUS_BOOTROM
tristate "Greybus Bootrom Class driver"
- ---help---
+ help
Select this option if you have a device that follows the
Greybus Bootrom Class specification.
@@ -49,7 +49,7 @@ config GREYBUS_BOOTROM
config GREYBUS_CAMERA
tristate "Greybus Camera Class driver"
depends on MEDIA_SUPPORT && LEDS_CLASS_FLASH && BROKEN
- ---help---
+ help
Select this option if you have a device that follows the
Greybus Camera Class specification.
@@ -59,7 +59,7 @@ config GREYBUS_CAMERA
config GREYBUS_FIRMWARE
tristate "Greybus Firmware Download Class driver"
depends on SPI
- ---help---
+ help
Select this option if you have a device that follows the
Greybus Firmware Download Class specification.
@@ -69,7 +69,7 @@ config GREYBUS_FIRMWARE
config GREYBUS_HID
tristate "Greybus HID Class driver"
depends on HID && INPUT
- ---help---
+ help
Select this option if you have a device that follows the
Greybus HID Class specification.
@@ -79,7 +79,7 @@ config GREYBUS_HID
config GREYBUS_LIGHT
tristate "Greybus LED Class driver"
depends on LEDS_CLASS
- ---help---
+ help
Select this option if you have a device that follows the
Greybus LED Class specification.
@@ -88,7 +88,7 @@ config GREYBUS_LIGHT
config GREYBUS_LOG
tristate "Greybus Debug Log Class driver"
- ---help---
+ help
Select this option if you have a device that follows the
Greybus Debug Log Class specification.
@@ -97,7 +97,7 @@ config GREYBUS_LOG
config GREYBUS_LOOPBACK
tristate "Greybus Loopback Class driver"
- ---help---
+ help
Select this option if you have a device that follows the
Greybus Debug Log Class specification.
@@ -107,7 +107,7 @@ config GREYBUS_LOOPBACK
config GREYBUS_POWER
tristate "Greybus Powersupply Class driver"
depends on POWER_SUPPLY
- ---help---
+ help
Select this option if you have a device that follows the
Greybus Powersupply Class specification.
@@ -116,7 +116,7 @@ config GREYBUS_POWER
config GREYBUS_RAW
tristate "Greybus Raw Class driver"
- ---help---
+ help
Select this option if you have a device that follows the
Greybus Raw Class specification.
@@ -125,7 +125,7 @@ config GREYBUS_RAW
config GREYBUS_VIBRATOR
tristate "Greybus Vibrator Motor Class driver"
- ---help---
+ help
Select this option if you have a device that follows the
Greybus Vibrator Motor Class specification.
@@ -134,7 +134,7 @@ config GREYBUS_VIBRATOR
menuconfig GREYBUS_BRIDGED_PHY
tristate "Greybus Bridged PHY Class drivers"
- ---help---
+ help
Select this option to pick from a variety of Greybus Bridged
PHY class drivers. These drivers emulate a number of
different "traditional" busses by tunneling them over Greybus.
@@ -149,7 +149,7 @@ config GREYBUS_GPIO
tristate "Greybus GPIO Bridged PHY driver"
depends on GPIOLIB
select GPIOLIB_IRQCHIP
- ---help---
+ help
Select this option if you have a device that follows the
Greybus GPIO Bridged PHY Class specification.
@@ -159,7 +159,7 @@ config GREYBUS_GPIO
config GREYBUS_I2C
tristate "Greybus I2C Bridged PHY driver"
depends on I2C
- ---help---
+ help
Select this option if you have a device that follows the
Greybus I2C Bridged PHY Class specification.
@@ -169,7 +169,7 @@ config GREYBUS_I2C
config GREYBUS_PWM
tristate "Greybus PWM Bridged PHY driver"
depends on PWM
- ---help---
+ help
Select this option if you have a device that follows the
Greybus PWM Bridged PHY Class specification.
@@ -179,7 +179,7 @@ config GREYBUS_PWM
config GREYBUS_SDIO
tristate "Greybus SDIO Bridged PHY driver"
depends on MMC
- ---help---
+ help
Select this option if you have a device that follows the
Greybus SDIO Bridged PHY Class specification.
@@ -189,7 +189,7 @@ config GREYBUS_SDIO
config GREYBUS_SPI
tristate "Greybus SPI Bridged PHY driver"
depends on SPI
- ---help---
+ help
Select this option if you have a device that follows the
Greybus SPI Bridged PHY Class specification.
@@ -199,7 +199,7 @@ config GREYBUS_SPI
config GREYBUS_UART
tristate "Greybus UART Bridged PHY driver"
depends on TTY
- ---help---
+ help
Select this option if you have a device that follows the
Greybus UART Bridged PHY Class specification.
@@ -209,7 +209,7 @@ config GREYBUS_UART
config GREYBUS_USB
tristate "Greybus USB Host Bridged PHY driver"
depends on USB
- ---help---
+ help
Select this option if you have a device that follows the
Greybus USB Host Bridged PHY Class specification.
@@ -221,7 +221,7 @@ endif # GREYBUS_BRIDGED_PHY
config GREYBUS_ARCHE
tristate "Greybus Arche Platform driver"
depends on USB_HSIC_USB3613 || COMPILE_TEST
- ---help---
+ help
Select this option if you have an Arche device.
To compile this code as a module, chose M here: the module
--
2.11.0
^ permalink raw reply related [relevance 4%]
* Re: staging/greybus: undefined Kconfig symbols
2016-09-21 7:39 0% ` Greg KH
@ 2016-09-21 10:25 0% ` Valentin Rothberg
0 siblings, 0 replies; 15+ results
From: Valentin Rothberg @ 2016-09-21 10:25 UTC (permalink / raw)
To: Greg KH; +Cc: LKML
On Wed, Sep 21, 2016 at 9:39 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Wed, Sep 21, 2016 at 08:30:01AM +0200, Valentin Rothberg wrote:
>> Hi Greg,
>
> <fixing odd email address you used for me...>
I was a little surprised, too, but that's the one in the signed-off
field in the greybus commits, so I used it.
>> checkkconfigsymbols.py found some undefined Kconfig symbols (see
>> below) in the Makefile and Kconfig file. I could not find any patch
>> adding those symbols. Are there patches queued somewhere else?
>>
>> Best regards,
>> Valentin
>>
>> GREYBUS_AUDIO_MSM8994
>> Referencing files: drivers/staging/greybus/Makefile
>> Similar symbols: GREYBUS_AUDIO, GREYBUS_GPIO, GREYBUS_SDIO, GREYBUS_USB
>> Commits changing symbol:
>> - d4f56b47a8fa ("staging: greybus: Add drivers/staging/greybus to the build")
>
> This one is tricky, as parts of this audio driver depended on an
> out-of-tree qualcomm audio driver. It will be unwound over time to not
> depend on that mess.
>
>> MEDIA
>> Referencing files: drivers/staging/greybus/Kconfig
>> Similar symbols: COMEDI, EDAC, EISA, HID_CMEDIA, LANMEDIA, MDIO,
>> MEDIA_CEC, MEDIA_TUNER, MEMDMA0, MEMDMA1
>> Commits changing symbol:
>> - d4f56b47a8fa ("staging: greybus: Add drivers/staging/greybus to the build")
>> - 847175e8e660 ("greybus: audio: Fetch jack_mask, button_mask from
>> module's topology data")
>> - 64a7e2cceb75 ("greybus: audio: Added jack support to audio module")
>
> Ugh, this should be CONFIG_MEDIA_SUPPORT, right? If so, I'll make a
> patch to change this, that was my fault.
Yes, since it's a camera driver, MEDIA_SUPPORT seems to be the good dependency.
>> USB_HSIC_USB3613
>> Referencing files: drivers/staging/greybus/Makefile
>> Similar symbols: USB_FSL_USB2, USB_GSPCA_SPCA561, USB_GSPCA_STK1135,
>> USB_GSPCA_T613, USB_HCD_SSB, USB_HSIC_USB3503, USB_HSIC_USB4604,
>> USB_RENESAS_USB3, USB_SI4713, USB_SISUSBVGA
>> Commits changing symbol:
>> - d4f56b47a8fa ("staging: greybus: Add drivers/staging/greybus to the build")
>> - 7d0493d191ab ("greybus: only build arche platform driver if usb3613
>> is enabled")
>
> This is a driver that has yet to be queued up, give us a few weeks to
> add it, and then it will probably be merged into the arche-platform
> driver as they both depend on each other.
Okay. I won't report these symbols in the future :)
Thanks,
Valentin
^ permalink raw reply [relevance 0%]
* Re: staging/greybus: undefined Kconfig symbols
2016-09-21 6:30 6% staging/greybus: undefined Kconfig symbols Valentin Rothberg
@ 2016-09-21 7:39 0% ` Greg KH
2016-09-21 10:25 0% ` Valentin Rothberg
0 siblings, 1 reply; 15+ results
From: Greg KH @ 2016-09-21 7:39 UTC (permalink / raw)
To: Valentin Rothberg; +Cc: LKML
On Wed, Sep 21, 2016 at 08:30:01AM +0200, Valentin Rothberg wrote:
> Hi Greg,
<fixing odd email address you used for me...>
> checkkconfigsymbols.py found some undefined Kconfig symbols (see
> below) in the Makefile and Kconfig file. I could not find any patch
> adding those symbols. Are there patches queued somewhere else?
>
> Best regards,
> Valentin
>
> GREYBUS_AUDIO_MSM8994
> Referencing files: drivers/staging/greybus/Makefile
> Similar symbols: GREYBUS_AUDIO, GREYBUS_GPIO, GREYBUS_SDIO, GREYBUS_USB
> Commits changing symbol:
> - d4f56b47a8fa ("staging: greybus: Add drivers/staging/greybus to the build")
This one is tricky, as parts of this audio driver depended on an
out-of-tree qualcomm audio driver. It will be unwound over time to not
depend on that mess.
> MEDIA
> Referencing files: drivers/staging/greybus/Kconfig
> Similar symbols: COMEDI, EDAC, EISA, HID_CMEDIA, LANMEDIA, MDIO,
> MEDIA_CEC, MEDIA_TUNER, MEMDMA0, MEMDMA1
> Commits changing symbol:
> - d4f56b47a8fa ("staging: greybus: Add drivers/staging/greybus to the build")
> - 847175e8e660 ("greybus: audio: Fetch jack_mask, button_mask from
> module's topology data")
> - 64a7e2cceb75 ("greybus: audio: Added jack support to audio module")
Ugh, this should be CONFIG_MEDIA_SUPPORT, right? If so, I'll make a
patch to change this, that was my fault.
> USB_HSIC_USB3613
> Referencing files: drivers/staging/greybus/Makefile
> Similar symbols: USB_FSL_USB2, USB_GSPCA_SPCA561, USB_GSPCA_STK1135,
> USB_GSPCA_T613, USB_HCD_SSB, USB_HSIC_USB3503, USB_HSIC_USB4604,
> USB_RENESAS_USB3, USB_SI4713, USB_SISUSBVGA
> Commits changing symbol:
> - d4f56b47a8fa ("staging: greybus: Add drivers/staging/greybus to the build")
> - 7d0493d191ab ("greybus: only build arche platform driver if usb3613
> is enabled")
This is a driver that has yet to be queued up, give us a few weeks to
add it, and then it will probably be merged into the arche-platform
driver as they both depend on each other.
thanks,
greg k-h
^ permalink raw reply [relevance 0%]
* staging/greybus: undefined Kconfig symbols
@ 2016-09-21 6:30 6% Valentin Rothberg
2016-09-21 7:39 0% ` Greg KH
0 siblings, 1 reply; 15+ results
From: Valentin Rothberg @ 2016-09-21 6:30 UTC (permalink / raw)
To: gregkh; +Cc: LKML
Hi Greg,
checkkconfigsymbols.py found some undefined Kconfig symbols (see
below) in the Makefile and Kconfig file. I could not find any patch
adding those symbols. Are there patches queued somewhere else?
Best regards,
Valentin
GREYBUS_AUDIO_MSM8994
Referencing files: drivers/staging/greybus/Makefile
Similar symbols: GREYBUS_AUDIO, GREYBUS_GPIO, GREYBUS_SDIO, GREYBUS_USB
Commits changing symbol:
- d4f56b47a8fa ("staging: greybus: Add drivers/staging/greybus to the build")
MEDIA
Referencing files: drivers/staging/greybus/Kconfig
Similar symbols: COMEDI, EDAC, EISA, HID_CMEDIA, LANMEDIA, MDIO,
MEDIA_CEC, MEDIA_TUNER, MEMDMA0, MEMDMA1
Commits changing symbol:
- d4f56b47a8fa ("staging: greybus: Add drivers/staging/greybus to the build")
- 847175e8e660 ("greybus: audio: Fetch jack_mask, button_mask from
module's topology data")
- 64a7e2cceb75 ("greybus: audio: Added jack support to audio module")
USB_HSIC_USB3613
Referencing files: drivers/staging/greybus/Makefile
Similar symbols: USB_FSL_USB2, USB_GSPCA_SPCA561, USB_GSPCA_STK1135,
USB_GSPCA_T613, USB_HCD_SSB, USB_HSIC_USB3503, USB_HSIC_USB4604,
USB_RENESAS_USB3, USB_SI4713, USB_SISUSBVGA
Commits changing symbol:
- d4f56b47a8fa ("staging: greybus: Add drivers/staging/greybus to the build")
- 7d0493d191ab ("greybus: only build arche platform driver if usb3613
is enabled")
^ permalink raw reply [relevance 6%]
Results 1-15 of 15 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2016-09-21 6:30 6% staging/greybus: undefined Kconfig symbols Valentin Rothberg
2016-09-21 7:39 0% ` Greg KH
2016-09-21 10:25 0% ` Valentin Rothberg
2019-04-20 9:21 4% [PATCH] staging: greybus: use help instead of ---help--- in Kconfig MosesChristopher
2021-12-22 9:54 14% Addition of config USB_HSIC_USB3613 soon? Lukas Bulwahn
2021-12-22 9:58 6% ` Greg Kroah-Hartman
2021-12-22 10:10 6% ` Lukas Bulwahn
2023-03-10 17:09 [PATCH] staging: greybus: fix exceeds line length Khadija Kamran
2023-03-10 19:40 ` Dan Carpenter
2023-03-13 4:30 7% ` Lukas Bulwahn
2023-03-29 7:52 6% Multiple undefined configuration options are dependent in Kconfig under the v6.3-rc4 drivers directory 孙滢
2023-03-29 22:34 0% ` Damien Le Moal
2023-03-29 22:34 0% ` Damien Le Moal
2023-04-10 23:40 0% ` Serge Semin
2023-04-10 23:40 0% ` Serge Semin
2023-04-14 8:18 0% ` Jiaxun Yang
2023-04-21 13:19 0% ` Serge Semin
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.