* Increase ARCH_NR_GPIO for ARCH_ASPEED? @ 2019-02-14 23:16 Tao Ren 2019-02-15 1:06 ` [Potential Spoof] " Tao Ren 0 siblings, 1 reply; 15+ messages in thread From: Tao Ren @ 2019-02-14 23:16 UTC (permalink / raw) To: OpenBMC Maillist Hi, I got following error while booting up openbmc linux 4.18 on Facebook YAMP BMC (ast2500 based), and it's because total 594 GPIO pins are provided by aspeed soc and i/o expanders on YAMP board: gpiochip_find_base: cannot find free range gpiochip_add_data_with_key: GPIOs 0..15 (pca9555) failed to register I'm wondering if it's good idea to increase ARCH_NR_GPIO default value to the "next level" (1024) for ARCH_ASPEED? If not, any other suggestions for this problem? Thanks, Tao ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Potential Spoof] Increase ARCH_NR_GPIO for ARCH_ASPEED? 2019-02-14 23:16 Increase ARCH_NR_GPIO for ARCH_ASPEED? Tao Ren @ 2019-02-15 1:06 ` Tao Ren 2019-02-15 1:42 ` Andrew Jeffery 0 siblings, 1 reply; 15+ messages in thread From: Tao Ren @ 2019-02-15 1:06 UTC (permalink / raw) To: openbmc@lists.ozlabs.org On 2/14/19 3:16 PM, Tao Ren wrote: > Hi, > > I got following error while booting up openbmc linux 4.18 on Facebook YAMP BMC (ast2500 based), and it's because total 594 GPIO pins are provided by aspeed soc and i/o expanders on YAMP board: > > gpiochip_find_base: cannot find free range > gpiochip_add_data_with_key: GPIOs 0..15 (pca9555) failed to register > > I'm wondering if it's good idea to increase ARCH_NR_GPIO default value to the "next level" (1024) for ARCH_ASPEED? If not, any other suggestions for this problem? I forgot to mention the current value of ARCH_NR_GPIO for ARCH_ASPEED: it's 512 (but YAMP BMC provides 594 GPIO pins). - Tao ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Potential Spoof] Increase ARCH_NR_GPIO for ARCH_ASPEED? 2019-02-15 1:06 ` [Potential Spoof] " Tao Ren @ 2019-02-15 1:42 ` Andrew Jeffery 2019-02-15 2:01 ` Tao Ren 0 siblings, 1 reply; 15+ messages in thread From: Andrew Jeffery @ 2019-02-15 1:42 UTC (permalink / raw) To: Tao Ren, openbmc On Fri, 15 Feb 2019, at 11:36, Tao Ren wrote: > On 2/14/19 3:16 PM, Tao Ren wrote: > > Hi, > > > > I got following error while booting up openbmc linux 4.18 on Facebook YAMP BMC (ast2500 based), and it's because total 594 GPIO pins are provided by aspeed soc and i/o expanders on YAMP board: > > > > gpiochip_find_base: cannot find free range > > gpiochip_add_data_with_key: GPIOs 0..15 (pca9555) failed to register > > > > I'm wondering if it's good idea to increase ARCH_NR_GPIO default value to the "next level" (1024) for ARCH_ASPEED? If not, any other suggestions for this problem? I don't know that there's much other choice, but beware that changing the value will impact userspace if you're using the sysfs interface (which you ideally you shouldn't be, as it's deprecated), as the base addresses of the gpiochips will change. Andrew ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Increase ARCH_NR_GPIO for ARCH_ASPEED? 2019-02-15 1:42 ` Andrew Jeffery @ 2019-02-15 2:01 ` Tao Ren 2019-02-18 2:47 ` Andrew Jeffery 0 siblings, 1 reply; 15+ messages in thread From: Tao Ren @ 2019-02-15 2:01 UTC (permalink / raw) To: Andrew Jeffery, openbmc@lists.ozlabs.org On 2/14/19 5:42 PM, Andrew Jeffery wrote: > I don't know that there's much other choice, but beware that changing > the value will impact userspace if you're using the sysfs interface (which > you ideally you shouldn't be, as it's deprecated), as the base addresses > of the gpiochips will change. > > Andrew Thank you Andrew for the comments. Hopefully nobody in the community will be impacted by the patch; if unfortunately some apps are broken (due to the dependency on sysfs-gpio), I'm happy to help with the fix. Thanks, - Tao ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Increase ARCH_NR_GPIO for ARCH_ASPEED? 2019-02-15 2:01 ` Tao Ren @ 2019-02-18 2:47 ` Andrew Jeffery 2019-02-18 4:56 ` Tao Ren 0 siblings, 1 reply; 15+ messages in thread From: Andrew Jeffery @ 2019-02-18 2:47 UTC (permalink / raw) To: Tao Ren, openbmc On Fri, 15 Feb 2019, at 12:31, Tao Ren wrote: > On 2/14/19 5:42 PM, Andrew Jeffery wrote: > > I don't know that there's much other choice, but beware that changing > > the value will impact userspace if you're using the sysfs interface (which > > you ideally you shouldn't be, as it's deprecated), as the base addresses > > of the gpiochips will change. > > > > Andrew > > Thank you Andrew for the comments. Hopefully nobody in the community > will be impacted by the patch; if unfortunately some apps are broken > (due to the dependency on sysfs-gpio), I'm happy to help with the fix. It's not necessarily an easy thing to fix if userspace is relying on fixed numbering (which isn't ideal, but it may). You can't fix netbooting a new kernel containing the change with an old userspace that isn't aware of it. However, there's no reason you can't narrow the change to only apply to your system (rather than do it in the base defconfig and affect all systems). Andrew > > Thanks, > > - Tao ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Increase ARCH_NR_GPIO for ARCH_ASPEED? 2019-02-18 2:47 ` Andrew Jeffery @ 2019-02-18 4:56 ` Tao Ren 2019-02-18 5:11 ` Andrew Jeffery 0 siblings, 1 reply; 15+ messages in thread From: Tao Ren @ 2019-02-18 4:56 UTC (permalink / raw) To: Andrew Jeffery, openbmc@lists.ozlabs.org Hi Andrew, On 2/17/19, 6:48 PM, "Andrew Jeffery" <andrew@aj.id.au> wrote: > However, there's no reason you can't narrow the change to only apply > to your system (rather than do it in the base defconfig and affect all > systems). Perhaps it's my lack of greater knowledge on kconfig; I actually tried a few options but couldn't find a nice way to apply the change to my system only. At first, I tried to customize ARCH_NR_GPIO in my <old.config> file, but the value was set to default (or ignored) by running "make olddefconfig". Then I added "input prompt" for ARCH_NR_GPIO option: customized value in <old.config> was applied while running "make olddefconfig", but my concern is the approach may impact more users? My third approach is what I proposed in this email thread (setting default ARCH_NR_GPIO to 1024 for ARCH_ASPEED). I'm looking forward for your suggestions. Thank you again. Best regards, Tao ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Increase ARCH_NR_GPIO for ARCH_ASPEED? 2019-02-18 4:56 ` Tao Ren @ 2019-02-18 5:11 ` Andrew Jeffery 2019-02-20 0:12 ` Tao Ren 0 siblings, 1 reply; 15+ messages in thread From: Andrew Jeffery @ 2019-02-18 5:11 UTC (permalink / raw) To: openbmc@lists.ozlabs.org, Tao Ren On Mon, 18 Feb 2019, at 15:26, Tao Ren wrote: > Hi Andrew, > > On 2/17/19, 6:48 PM, "Andrew Jeffery" <andrew@aj.id.au> wrote: > > However, there's no reason you can't narrow the change to only apply > > to your system (rather than do it in the base defconfig and affect all > > systems). > > Perhaps it's my lack of greater knowledge on kconfig; I actually tried > a few options but couldn't find a nice way to apply the change to my > system only. > > At first, I tried to customize ARCH_NR_GPIO in my <old.config> file, > but the value was set to default (or ignored) by running "make > olddefconfig". > > Then I added "input prompt" for ARCH_NR_GPIO option: customized value > in <old.config> was applied while running "make olddefconfig", but my > concern is the approach may impact more users? > > My third approach is what I proposed in this email thread (setting > default ARCH_NR_GPIO to 1024 for ARCH_ASPEED). > > I'm looking forward for your suggestions. Thank you again. As an example, for Tiogapass, you should be able to define `CONFIG_ARCH_NR_GPIO = 1024` in tiogapass.cfg: https://github.com/openbmc/meta-facebook/blob/master/meta-tiogapass/recipes-kernel/linux/linux-aspeed/tiogapass.cfg Andrew ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Increase ARCH_NR_GPIO for ARCH_ASPEED? 2019-02-18 5:11 ` Andrew Jeffery @ 2019-02-20 0:12 ` Tao Ren 2019-02-20 0:15 ` Andrew Jeffery 0 siblings, 1 reply; 15+ messages in thread From: Tao Ren @ 2019-02-20 0:12 UTC (permalink / raw) To: Andrew Jeffery, openbmc@lists.ozlabs.org Hi Andrew, On 2/17/19 9:11 PM, Andrew Jeffery wrote: > As an example, for Tiogapass, you should be able to define `CONFIG_ARCH_NR_GPIO = 1024` in tiogapass.cfg: > > https://github.com/openbmc/meta-facebook/blob/master/meta-tiogapass/recipes-kernel/linux/linux-aspeed/tiogapass.cfg I tried to define 'CONFIG_ARCH_NR_GPIO=1024' in <platform>.cfg, but still, it's reset to 0 by "make olddefconfig". Below are my steps (using the latest openbmc tree), and kindly let me know if I missed something: 1) added 'CONFIG_ARCH_NR_GPIO=1024' in meta-ibm/meta-romulus/recipes-kernel/linux/linux-aspeed/romulus.cfg 2) export TEMPLATECONF=meta-ibm/meta-romulus/conf 3) . openbmc-env 4) ran "bitbake linux-aspeed" 5) checked build/tmp/work/romulus-openbmc-linux-gnueabi/linux-aspeed/4.19.21+gitAUTOINC+d808d27f70-r0/linux-romulus-standard-build/.config: CONFIG_ARCH_NR_GPIO is reset to 0. Thanks, - Tao ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Increase ARCH_NR_GPIO for ARCH_ASPEED? 2019-02-20 0:12 ` Tao Ren @ 2019-02-20 0:15 ` Andrew Jeffery 2019-02-20 0:17 ` Tao Ren 2019-02-22 0:55 ` Tao Ren 0 siblings, 2 replies; 15+ messages in thread From: Andrew Jeffery @ 2019-02-20 0:15 UTC (permalink / raw) To: openbmc@lists.ozlabs.org, Tao Ren On Wed, 20 Feb 2019, at 10:43, Tao Ren wrote: > Hi Andrew, > > On 2/17/19 9:11 PM, Andrew Jeffery wrote: > > As an example, for Tiogapass, you should be able to define `CONFIG_ARCH_NR_GPIO = 1024` in tiogapass.cfg: > > > > https://github.com/openbmc/meta-facebook/blob/master/meta-tiogapass/recipes-kernel/linux/linux-aspeed/tiogapass.cfg > > I tried to define 'CONFIG_ARCH_NR_GPIO=1024' in <platform>.cfg, but > still, it's reset to 0 by "make olddefconfig". > > Below are my steps (using the latest openbmc tree), and kindly let me > know if I missed something: > > 1) added 'CONFIG_ARCH_NR_GPIO=1024' in > meta-ibm/meta-romulus/recipes-kernel/linux/linux-aspeed/romulus.cfg > 2) export TEMPLATECONF=meta-ibm/meta-romulus/conf > 3) . openbmc-env > 4) ran "bitbake linux-aspeed" > 5) checked > build/tmp/work/romulus-openbmc-linux-gnueabi/linux-aspeed/4.19.21+gitAUTOINC+d808d27f70-r0/linux-romulus-standard-build/.config: CONFIG_ARCH_NR_GPIO is reset to 0. Ugh. I didn't try it myself, was just hoping that would work. Are you okay to keep digging into why? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Increase ARCH_NR_GPIO for ARCH_ASPEED? 2019-02-20 0:15 ` Andrew Jeffery @ 2019-02-20 0:17 ` Tao Ren 2019-02-22 0:55 ` Tao Ren 1 sibling, 0 replies; 15+ messages in thread From: Tao Ren @ 2019-02-20 0:17 UTC (permalink / raw) To: Andrew Jeffery, openbmc@lists.ozlabs.org On 2/19/19 4:15 PM, Andrew Jeffery wrote: > On Wed, 20 Feb 2019, at 10:43, Tao Ren wrote: >> Hi Andrew, >> >> On 2/17/19 9:11 PM, Andrew Jeffery wrote: >>> As an example, for Tiogapass, you should be able to define `CONFIG_ARCH_NR_GPIO = 1024` in tiogapass.cfg: >>> >>> https://github.com/openbmc/meta-facebook/blob/master/meta-tiogapass/recipes-kernel/linux/linux-aspeed/tiogapass.cfg >> >> I tried to define 'CONFIG_ARCH_NR_GPIO=1024' in <platform>.cfg, but >> still, it's reset to 0 by "make olddefconfig". >> >> Below are my steps (using the latest openbmc tree), and kindly let me >> know if I missed something: >> >> 1) added 'CONFIG_ARCH_NR_GPIO=1024' in >> meta-ibm/meta-romulus/recipes-kernel/linux/linux-aspeed/romulus.cfg >> 2) export TEMPLATECONF=meta-ibm/meta-romulus/conf >> 3) . openbmc-env >> 4) ran "bitbake linux-aspeed" >> 5) checked >> build/tmp/work/romulus-openbmc-linux-gnueabi/linux-aspeed/4.19.21+gitAUTOINC+d808d27f70-r0/linux-romulus-standard-build/.config: CONFIG_ARCH_NR_GPIO is reset to 0. > > Ugh. I didn't try it myself, was just hoping that would work. Are you okay > to keep digging into why? Sure. Let me run more testing, and will share you more details later.. - Tao ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Increase ARCH_NR_GPIO for ARCH_ASPEED? 2019-02-20 0:15 ` Andrew Jeffery 2019-02-20 0:17 ` Tao Ren @ 2019-02-22 0:55 ` Tao Ren 2019-02-25 1:55 ` Andrew Jeffery 1 sibling, 1 reply; 15+ messages in thread From: Tao Ren @ 2019-02-22 0:55 UTC (permalink / raw) To: Andrew Jeffery, openbmc@lists.ozlabs.org Hi Andrew, On 2/19/19 4:15 PM, Andrew Jeffery wrote: > On Wed, 20 Feb 2019, at 10:43, Tao Ren wrote: >> Hi Andrew, >> >> On 2/17/19 9:11 PM, Andrew Jeffery wrote: >>> As an example, for Tiogapass, you should be able to define `CONFIG_ARCH_NR_GPIO = 1024` in tiogapass.cfg: >>> >>> https://github.com/openbmc/meta-facebook/blob/master/meta-tiogapass/recipes-kernel/linux/linux-aspeed/tiogapass.cfg >> >> I tried to define 'CONFIG_ARCH_NR_GPIO=1024' in <platform>.cfg, but >> still, it's reset to 0 by "make olddefconfig". >> >> Below are my steps (using the latest openbmc tree), and kindly let me >> know if I missed something: >> >> 1) added 'CONFIG_ARCH_NR_GPIO=1024' in >> meta-ibm/meta-romulus/recipes-kernel/linux/linux-aspeed/romulus.cfg >> 2) export TEMPLATECONF=meta-ibm/meta-romulus/conf >> 3) . openbmc-env >> 4) ran "bitbake linux-aspeed" >> 5) checked >> build/tmp/work/romulus-openbmc-linux-gnueabi/linux-aspeed/4.19.21+gitAUTOINC+d808d27f70-r0/linux-romulus-standard-build/.config: CONFIG_ARCH_NR_GPIO is reset to 0. > > Ugh. I didn't try it myself, was just hoping that would work. Are you okay > to keep digging into why? Manually editing "ARCH_NR_GPIO" in <platform>.cfg doesn't work because ARCH_NR_GPIO symbol is "invisible" and user defined value will be ignored by "scripts/kconfig/conf". I compared a few other ways to fix/workaround the issue, but IMHO, increasing default ARCH_NR_GPIO for ARCH_ASPEED is better than other solutions. Please suggest. BTW, "CONFIG_GCC_PLUGINS=y" in meta-aspeed/recipes-kernel/linux/ast2500/defconfig is not included in the final .config because its dependency option PLUGIN_HOSTCC is not set. Thanks, - Tao ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Increase ARCH_NR_GPIO for ARCH_ASPEED? 2019-02-22 0:55 ` Tao Ren @ 2019-02-25 1:55 ` Andrew Jeffery 2019-02-25 19:04 ` Tao Ren 0 siblings, 1 reply; 15+ messages in thread From: Andrew Jeffery @ 2019-02-25 1:55 UTC (permalink / raw) To: Tao Ren, openbmc@lists.ozlabs.org On Fri, 22 Feb 2019, at 11:25, Tao Ren wrote: > Hi Andrew, > > On 2/19/19 4:15 PM, Andrew Jeffery wrote: > > On Wed, 20 Feb 2019, at 10:43, Tao Ren wrote: > >> Hi Andrew, > >> > >> On 2/17/19 9:11 PM, Andrew Jeffery wrote: > >>> As an example, for Tiogapass, you should be able to define `CONFIG_ARCH_NR_GPIO = 1024` in tiogapass.cfg: > >>> > >>> https://github.com/openbmc/meta-facebook/blob/master/meta-tiogapass/recipes-kernel/linux/linux-aspeed/tiogapass.cfg > >> > >> I tried to define 'CONFIG_ARCH_NR_GPIO=1024' in <platform>.cfg, but > >> still, it's reset to 0 by "make olddefconfig". > >> > >> Below are my steps (using the latest openbmc tree), and kindly let me > >> know if I missed something: > >> > >> 1) added 'CONFIG_ARCH_NR_GPIO=1024' in > >> meta-ibm/meta-romulus/recipes-kernel/linux/linux-aspeed/romulus.cfg > >> 2) export TEMPLATECONF=meta-ibm/meta-romulus/conf > >> 3) . openbmc-env > >> 4) ran "bitbake linux-aspeed" > >> 5) checked > >> build/tmp/work/romulus-openbmc-linux-gnueabi/linux-aspeed/4.19.21+gitAUTOINC+d808d27f70-r0/linux-romulus-standard-build/.config: CONFIG_ARCH_NR_GPIO is reset to 0. > > > > Ugh. I didn't try it myself, was just hoping that would work. Are you okay > > to keep digging into why? > > Manually editing "ARCH_NR_GPIO" in <platform>.cfg doesn't work because > ARCH_NR_GPIO symbol is "invisible" and user defined value will be > ignored by "scripts/kconfig/conf". I compared a few other ways to > fix/workaround the issue, but IMHO, increasing default ARCH_NR_GPIO for > ARCH_ASPEED is better than other solutions. Please suggest. Hrm. That's really unfortunate. Can you patch it in on your platform for the moment? We're going to have to come up with some more long term strategy. Whether that's making the symbol visible or migrating everyone off sysfs (which they should be doing anyway) I'm not sure. If we don't do either of those then I think we're going to have to audit userspace to find what will break. > > BTW, "CONFIG_GCC_PLUGINS=y" in > meta-aspeed/recipes-kernel/linux/ast2500/defconfig is not included in > the final .config because its dependency option PLUGIN_HOSTCC is not > set. Can you open an issue in https://github.com/openbmc/linux ? Cheers, Andrew > > > Thanks, > > - Tao > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Increase ARCH_NR_GPIO for ARCH_ASPEED? 2019-02-25 1:55 ` Andrew Jeffery @ 2019-02-25 19:04 ` Tao Ren 2019-02-25 23:32 ` Andrew Jeffery 0 siblings, 1 reply; 15+ messages in thread From: Tao Ren @ 2019-02-25 19:04 UTC (permalink / raw) To: Andrew Jeffery, openbmc@lists.ozlabs.org Hi Andrew, Thank you for looking into the issue. On 2/24/19 5:55 PM, Andrew Jeffery wrote: > > On Fri, 22 Feb 2019, at 11:25, Tao Ren wrote: >> Hi Andrew, >> >> On 2/19/19 4:15 PM, Andrew Jeffery wrote: >>> On Wed, 20 Feb 2019, at 10:43, Tao Ren wrote: >>>> Hi Andrew, >> Manually editing "ARCH_NR_GPIO" in <platform>.cfg doesn't work because >> ARCH_NR_GPIO symbol is "invisible" and user defined value will be >> ignored by "scripts/kconfig/conf". I compared a few other ways to >> fix/workaround the issue, but IMHO, increasing default ARCH_NR_GPIO for >> ARCH_ASPEED is better than other solutions. Please suggest. > > Hrm. That's really unfortunate. Can you patch it in on your platform for the > moment? We're going to have to come up with some more long term strategy. > Whether that's making the symbol visible or migrating everyone off sysfs > (which they should be doing anyway) I'm not sure. If we don't do either of > those then I think we're going to have to audit userspace to find what will > break. Make sense. I will keep the patch in my local tree as of now. >> BTW, "CONFIG_GCC_PLUGINS=y" in >> meta-aspeed/recipes-kernel/linux/ast2500/defconfig is not included in >> the final .config because its dependency option PLUGIN_HOSTCC is not >> set. > > Can you open an issue in https://github.com/openbmc/linux ? Sure. Opened issue https://github.com/openbmc/linux/issues/170 Cheers, - Tao ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Increase ARCH_NR_GPIO for ARCH_ASPEED? 2019-02-25 19:04 ` Tao Ren @ 2019-02-25 23:32 ` Andrew Jeffery 2019-02-26 22:32 ` Tao Ren 0 siblings, 1 reply; 15+ messages in thread From: Andrew Jeffery @ 2019-02-25 23:32 UTC (permalink / raw) To: Tao Ren, openbmc@lists.ozlabs.org On Tue, 26 Feb 2019, at 05:34, Tao Ren wrote: > Hi Andrew, > > Thank you for looking into the issue. > > On 2/24/19 5:55 PM, Andrew Jeffery wrote: > > > > On Fri, 22 Feb 2019, at 11:25, Tao Ren wrote: > >> Hi Andrew, > >> > >> On 2/19/19 4:15 PM, Andrew Jeffery wrote: > >>> On Wed, 20 Feb 2019, at 10:43, Tao Ren wrote: > >>>> Hi Andrew, > >> Manually editing "ARCH_NR_GPIO" in <platform>.cfg doesn't work because > >> ARCH_NR_GPIO symbol is "invisible" and user defined value will be > >> ignored by "scripts/kconfig/conf". I compared a few other ways to > >> fix/workaround the issue, but IMHO, increasing default ARCH_NR_GPIO for > >> ARCH_ASPEED is better than other solutions. Please suggest. > > > > Hrm. That's really unfortunate. Can you patch it in on your platform for the > > moment? We're going to have to come up with some more long term strategy. > > Whether that's making the symbol visible or migrating everyone off sysfs > > (which they should be doing anyway) I'm not sure. If we don't do either of > > those then I think we're going to have to audit userspace to find what will > > break. > > Make sense. I will keep the patch in my local tree as of now. You can still send a patch to meta-facebook that applies your change to the kernel tree. Don't keep it to yourself :D > > >> BTW, "CONFIG_GCC_PLUGINS=y" in > >> meta-aspeed/recipes-kernel/linux/ast2500/defconfig is not included in > >> the final .config because its dependency option PLUGIN_HOSTCC is not > >> set. > > > > Can you open an issue in https://github.com/openbmc/linux ? > > Sure. Opened issue https://github.com/openbmc/linux/issues/170 Thanks. > > > Cheers, > > - Tao > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Increase ARCH_NR_GPIO for ARCH_ASPEED? 2019-02-25 23:32 ` Andrew Jeffery @ 2019-02-26 22:32 ` Tao Ren 0 siblings, 0 replies; 15+ messages in thread From: Tao Ren @ 2019-02-26 22:32 UTC (permalink / raw) To: Andrew Jeffery, openbmc@lists.ozlabs.org On 2/25/19 3:32 PM, Andrew Jeffery wrote: >>> Hrm. That's really unfortunate. Can you patch it in on your platform for the >>> moment? We're going to have to come up with some more long term strategy. >>> Whether that's making the symbol visible or migrating everyone off sysfs >>> (which they should be doing anyway) I'm not sure. If we don't do either of >>> those then I think we're going to have to audit userspace to find what will >>> break. >> >> Make sense. I will keep the patch in my local tree as of now. > > You can still send a patch to meta-facebook that applies your change to the > kernel tree. Don't keep it to yourself :D Oh yes. I almost forget the option of having patch files :) Cheers, - Tao ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2019-02-26 22:32 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-02-14 23:16 Increase ARCH_NR_GPIO for ARCH_ASPEED? Tao Ren 2019-02-15 1:06 ` [Potential Spoof] " Tao Ren 2019-02-15 1:42 ` Andrew Jeffery 2019-02-15 2:01 ` Tao Ren 2019-02-18 2:47 ` Andrew Jeffery 2019-02-18 4:56 ` Tao Ren 2019-02-18 5:11 ` Andrew Jeffery 2019-02-20 0:12 ` Tao Ren 2019-02-20 0:15 ` Andrew Jeffery 2019-02-20 0:17 ` Tao Ren 2019-02-22 0:55 ` Tao Ren 2019-02-25 1:55 ` Andrew Jeffery 2019-02-25 19:04 ` Tao Ren 2019-02-25 23:32 ` Andrew Jeffery 2019-02-26 22:32 ` Tao Ren
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.