coreboot-kgpe-d16/util/sconfig/sconfig.tab.c_shipped

1526 lines
52 KiB
Plaintext
Raw Normal View History

device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
/* A Bison parser, made by GNU Bison 3.7.2. */
/* Bison implementation for Yacc-like parsers in C
Copyright (C) 1984, 1989-1990, 2000-2015, 2018-2020 Free Software Foundation,
Inc.
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>. */
/* As a special exception, you may create a larger work that contains
part or all of the Bison parser skeleton and distribute that work
under terms of your choice, so long as that work isn't itself a
parser generator using the skeleton or a modified version thereof
as a parser skeleton. Alternatively, if you modify or redistribute
the parser skeleton itself, you may (at your option) remove this
special exception, which will cause the skeleton and the resulting
Bison output files to be licensed under the GNU General Public
License without this special exception.
This special exception was added by the Free Software Foundation in
version 2.2 of Bison. */
/* C LALR(1) parser skeleton written by Richard Stallman, by
simplifying the original so-called "semantic" parser. */
/* DO NOT RELY ON FEATURES THAT ARE NOT DOCUMENTED in the manual,
especially those whose name start with YY_ or yy_. They are
private implementation details that can be changed or removed. */
/* All symbols defined below should begin with yy or YY, to avoid
infringing on user name space. This should be done even for local
variables, as they might otherwise be expanded by user macros.
There are some unavoidable exceptions within include files to
define necessary library symbols; they are noted "INFRINGES ON
USER NAME SPACE" below. */
/* Identify Bison output. */
#define YYBISON 1
/* Bison version. */
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
#define YYBISON_VERSION "3.7.2"
/* Skeleton name. */
#define YYSKELETON_NAME "yacc.c"
/* Pure parsers. */
#define YYPURE 0
/* Push parsers. */
#define YYPUSH 0
/* Pull parsers. */
#define YYPULL 1
/* First part of user prologue. */
/* sconfig, coreboot device tree compiler */
util/: Replace GPLv2 boiler plate with SPDX header Used commands: perl -i -p0e 's|\/\*[\s*]*.*is free software[:;][\s*]*you[\s*]*can[\s*]*redistribute[\s*]*it[\s*]*and\/or[\s*]*modify[\s*]*it[\s*]*under[\s*]*the[\s*]*terms[\s*]*of[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*as[\s*]*published[\s*]*by[\s*]*the[\s*]*Free[\s*]*Software[\s*]*Foundation[;,][\s*]*version[\s*]*2[\s*]*of[\s*]*the[\s*]*License.[\s*]*This[\s*]*program[\s*]*is[\s*]*distributed[\s*]*in[\s*]*the[\s*]*hope[\s*]*that[\s*]*it[\s*]*will[\s*]*be[\s*]*useful,[\s*]*but[\s*]*WITHOUT[\s*]*ANY[\s*]*WARRANTY;[\s*]*without[\s*]*even[\s*]*the[\s*]*implied[\s*]*warranty[\s*]*of[\s*]*MERCHANTABILITY[\s*]*or[\s*]*FITNESS[\s*]*FOR[\s*]*A[\s*]*PARTICULAR[\s*]*PURPOSE.[\s*]*See[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*for[\s*]*more[\s*]*details.[\s*]*\*\/|/* SPDX-License-Identifier: GPL-2.0-only */|' $(cat filelist) perl -i -p0e 's|This[\s*]*program[\s*]*is[\s*]*free[\s*]*software[:;][\s*]*you[\s*]*can[\s*]*redistribute[\s*]*it[\s*]*and/or[\s*]*modify[\s*]*it[\s*]*under[\s*]*the[\s*]*terms[\s*]*of[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*as[\s*]*published[\s*]*by[\s*]*the[\s*]*Free[\s*]*Software[\s*]*Foundation[;,][\s*]*either[\s*]*version[\s*]*2[\s*]*of[\s*]*the[\s*]*License,[\s*]*or[\s*]*.at[\s*]*your[\s*]*option.*[\s*]*any[\s*]*later[\s*]*version.[\s*]*This[\s*]*program[\s*]*is[\s*]*distributed[\s*]*in[\s*]*the[\s*]*hope[\s*]*that[\s*]*it[\s*]*will[\s*]*be[\s*]*useful,[\s*]*but[\s*]*WITHOUT[\s*]*ANY[\s*]*WARRANTY;[\s*]*without[\s*]*even[\s*]*the[\s*]*implied[\s*]*warranty[\s*]*of[\s*]*MERCHANTABILITY[\s*]*or[\s*]*FITNESS[\s*]*FOR[\s*]*A[\s*]*PARTICULAR[\s*]*PURPOSE.[\s*]*See[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*for[\s*]*more[\s*]*details.[\s*]*\*\/|/* SPDX-License-Identifier: GPL-2.0-or-later */|' $(cat filelist) perl -i -p0e 's|\/\*[\s*]*.*This[\s*#]*program[\s*#]*is[\s*#]*free[\s*#]*software[;:,][\s*#]*you[\s*#]*can[\s*#]*redistribute[\s*#]*it[\s*#]*and/or[\s*#]*modify[\s*#]*it[\s*#]*under[\s*#]*the[\s*#]*terms[\s*#]*of[\s*#]*the[\s*#]*GNU[\s*#]*General[\s*#]*Public[\s*#]*License[\s*#]*as[\s*#]*published[\s*#]*by[\s*#]*the[\s*#]*Free[\s*#]*Software[\s*#]*Foundation[;:,][\s*#]*either[\s*#]*version[\s*#]*3[\s*#]*of[\s*#]*the[\s*#]*License[;:,][\s*#]*or[\s*#]*.at[\s*#]*your[\s*#]*option.*[\s*#]*any[\s*#]*later[\s*#]*version.[\s*#]*This[\s*#]*program[\s*#]*is[\s*#]*distributed[\s*#]*in[\s*#]*the[\s*#]*hope[\s*#]*that[\s*#]*it[\s*#]*will[\s*#]*be[\s*#]*useful[;:,][\s*#]*but[\s*#]*WITHOUT[\s*#]*ANY[\s*#]*WARRANTY[;:,][\s*#]*without[\s*#]*even[\s*#]*the[\s*#]*implied[\s*#]*warranty[\s*#]*of[\s*#]*MERCHANTABILITY[\s*#]*or[\s*#]*FITNESS[\s*#]*FOR[\s*#]*A[\s*#]*PARTICULAR[\s*#]*PURPOSE.[\s*#]*See[\s*#]*the[\s*#]*GNU[\s*#]*General[\s*#]*Public[\s*#]*License[\s*#]*for[\s*#]*more[\s*#]*details.[\s*]*\*\/|/* SPDX-License-Identifier: GPL-3.0-or-later */|' $(cat filelist) perl -i -p0e 's|(\#\#*)[\w]*.*is free software[:;][\#\s]*you[\#\s]*can[\#\s]*redistribute[\#\s]*it[\#\s]*and\/or[\#\s]*modify[\#\s]*it[\s\#]*under[\s \#]*the[\s\#]*terms[\s\#]*of[\s\#]*the[\s\#]*GNU[\s\#]*General[\s\#]*Public[\s\#]*License[\s\#]*as[\s\#]*published[\s\#]*by[\s\#]*the[\s\#]*Free[\s\#]*Software[\s\#]*Foundation[;,][\s\#]*version[\s\#]*2[\s\#]*of[\s\#]*the[\s\#]*License.*[\s\#]*This[\s\#]*program[\s\#]*is[\s\#]*distributed[\s\#]*in[\s\#]*the[\s\#]*hope[\s\#]*that[\s\#]*it[\s\#]*will[\#\s]*be[\#\s]*useful,[\#\s]*but[\#\s]*WITHOUT[\#\s]*ANY[\#\s]*WARRANTY;[\#\s]*without[\#\s]*even[\#\s]*the[\#\s]*implied[\#\s]*warranty[\#\s]*of[\#\s]*MERCHANTABILITY[\#\s]*or[\#\s]*FITNESS[\#\s]*FOR[\#\s]*A[\#\s]*PARTICULAR[\#\s]*PURPOSE.[\#\s]*See[\#\s]*the[\#\s]*GNU[\#\s]*General[\#\s]*Public[\#\s]*License[\#\s]*for[\#\s]*more[\#\s]*details.\s(#* *\n)*|\1 SPDX-License-Identifier: GPL-2.0-only\n\n|' $(cat filelist) perl -i -p0e 's|(\#\#*)[\w*]*.*is free software[:;][\s*]*you[\s*]*can[\s*]*redistribute[\s*]*it[\s*]*and\/or[\s*]*modify[\s*]*it[\s*]*under[\s*]*the[\s*]*terms[\s*]*of[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*as[\s*]*published[\s*]*by[\s*]*the[\s*]*Free[\s*]*Software[\s*]*Foundation[;,][\s*]*version[\s*]*2[\s*]*of[\s*]*the[\s*]*License.[\s*]*This[\s*]*program[\s*]*is[\s*]*distributed[\s*]*in[\s*]*the[\s*]*hope[\s*]*that[\s*]*it[\s*]*will[\s*]*be[\s*]*useful,[\s*]*but[\s*]*WITHOUT[\s*]*ANY[\s*]*WARRANTY;[\s*]*without[\s*]*even[\s*]*the[\s*]*implied[\s*]*warranty[\s*]*of[\s*]*MERCHANTABILITY[\s*]*or[\s*]*FITNESS[\s*]*FOR[\s*]*A[\s*]*PARTICULAR[\s*]*PURPOSE.[\s*]*See[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*for[\s*]*more[\s*]*details.\s(#* *\n)*|\1 SPDX-License-Identifier: GPL-2.0-only\n\n|' $(cat filelist) Change-Id: I1008a63b804f355a916221ac994701d7584f60ff Signed-off-by: Patrick Georgi <pgeorgi@google.com> Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41177 Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-08 20:48:04 +02:00
/* SPDX-License-Identifier: GPL-2.0-only */
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
#include <stdint.h>
#include "sconfig.h"
int yylex();
void yyerror(const char *s);
static struct bus *cur_parent;
static struct chip_instance *cur_chip_instance;
sconfig: Add support for firmware configuration This change adds support to sconfig for generating the firmware configuration field and option definitions in devicetree.cb. In addition these fields and options can be used to probe for a device and have that device be disabled if it is not found at boot time. New tokens: fw_config: top level token, table can be defined before chips field: define field in the mask with the start and end bits option: define option in a field with the value of the field probe: indicate that a device should probe by field and option Example: fw_config field FEATURE 0 0 option DISABLE 0 option ENABLE 1 end end chip drivers/generic/feature device generic 0 on probe FEATURE ENABLE end end Variants can add new fields and add new options to existing fields in overridetree.cb but cannot redefine an existing option. Devices can have multiple probe tokens, and the device will be considered to be found if any of them return true. The output from defining this field are: 1) the various fields and options will be added as macro constants to static.h and can be used by fw_config for probing. 2) the probe entries will result in a list of fields/options to probe that is added to the resulting struct device and handled by coreboot. BUG=b:147462631 Signed-off-by: Duncan Laurie <dlaurie@google.com> Change-Id: I8aea63e577d933aea09e0d0b09470929cc96e0de Reviewed-on: https://review.coreboot.org/c/coreboot/+/41440 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-05-16 00:39:08 +02:00
static struct fw_config_field *cur_field;
# ifndef YY_CAST
# ifdef __cplusplus
# define YY_CAST(Type, Val) static_cast<Type> (Val)
# define YY_REINTERPRET_CAST(Type, Val) reinterpret_cast<Type> (Val)
# else
# define YY_CAST(Type, Val) ((Type) (Val))
# define YY_REINTERPRET_CAST(Type, Val) ((Type) (Val))
# endif
# endif
# ifndef YY_NULLPTR
# if defined __cplusplus
# if 201103L <= __cplusplus
# define YY_NULLPTR nullptr
# else
# define YY_NULLPTR 0
# endif
# else
# define YY_NULLPTR ((void*)0)
# endif
# endif
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
#include "sconfig.tab.h_shipped"
/* Symbol kind. */
enum yysymbol_kind_t
{
YYSYMBOL_YYEMPTY = -2,
YYSYMBOL_YYEOF = 0, /* "end of file" */
YYSYMBOL_YYerror = 1, /* error */
YYSYMBOL_YYUNDEF = 2, /* "invalid token" */
YYSYMBOL_CHIP = 3, /* CHIP */
YYSYMBOL_DEVICE = 4, /* DEVICE */
YYSYMBOL_REGISTER = 5, /* REGISTER */
YYSYMBOL_ALIAS = 6, /* ALIAS */
YYSYMBOL_REFERENCE = 7, /* REFERENCE */
YYSYMBOL_ASSOCIATION = 8, /* ASSOCIATION */
YYSYMBOL_BOOL = 9, /* BOOL */
YYSYMBOL_STATUS = 10, /* STATUS */
YYSYMBOL_MANDATORY = 11, /* MANDATORY */
YYSYMBOL_BUS = 12, /* BUS */
YYSYMBOL_RESOURCE = 13, /* RESOURCE */
YYSYMBOL_END = 14, /* END */
YYSYMBOL_EQUALS = 15, /* EQUALS */
YYSYMBOL_HEX = 16, /* HEX */
YYSYMBOL_STRING = 17, /* STRING */
YYSYMBOL_PCI = 18, /* PCI */
YYSYMBOL_PNP = 19, /* PNP */
YYSYMBOL_I2C = 20, /* I2C */
YYSYMBOL_APIC = 21, /* APIC */
YYSYMBOL_CPU_CLUSTER = 22, /* CPU_CLUSTER */
YYSYMBOL_CPU = 23, /* CPU */
YYSYMBOL_DOMAIN = 24, /* DOMAIN */
YYSYMBOL_IRQ = 25, /* IRQ */
YYSYMBOL_DRQ = 26, /* DRQ */
YYSYMBOL_SLOT_DESC = 27, /* SLOT_DESC */
YYSYMBOL_IO = 28, /* IO */
YYSYMBOL_NUMBER = 29, /* NUMBER */
YYSYMBOL_SUBSYSTEMID = 30, /* SUBSYSTEMID */
YYSYMBOL_INHERIT = 31, /* INHERIT */
YYSYMBOL_IOAPIC_IRQ = 32, /* IOAPIC_IRQ */
YYSYMBOL_IOAPIC = 33, /* IOAPIC */
YYSYMBOL_PCIINT = 34, /* PCIINT */
YYSYMBOL_GENERIC = 35, /* GENERIC */
YYSYMBOL_SPI = 36, /* SPI */
YYSYMBOL_USB = 37, /* USB */
YYSYMBOL_MMIO = 38, /* MMIO */
YYSYMBOL_LPC = 39, /* LPC */
YYSYMBOL_ESPI = 40, /* ESPI */
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
YYSYMBOL_GPIO = 41, /* GPIO */
YYSYMBOL_FW_CONFIG_TABLE = 42, /* FW_CONFIG_TABLE */
YYSYMBOL_FW_CONFIG_FIELD = 43, /* FW_CONFIG_FIELD */
YYSYMBOL_FW_CONFIG_OPTION = 44, /* FW_CONFIG_OPTION */
YYSYMBOL_FW_CONFIG_PROBE = 45, /* FW_CONFIG_PROBE */
YYSYMBOL_YYACCEPT = 46, /* $accept */
YYSYMBOL_devtree = 47, /* devtree */
YYSYMBOL_chipchildren = 48, /* chipchildren */
YYSYMBOL_devicechildren = 49, /* devicechildren */
YYSYMBOL_chip = 50, /* chip */
YYSYMBOL_51_1 = 51, /* @1 */
YYSYMBOL_device = 52, /* device */
YYSYMBOL_53_2 = 53, /* @2 */
YYSYMBOL_54_3 = 54, /* @3 */
YYSYMBOL_alias = 55, /* alias */
YYSYMBOL_status = 56, /* status */
YYSYMBOL_resource = 57, /* resource */
YYSYMBOL_reference = 58, /* reference */
YYSYMBOL_registers = 59, /* registers */
YYSYMBOL_subsystemid = 60, /* subsystemid */
YYSYMBOL_ioapic_irq = 61, /* ioapic_irq */
YYSYMBOL_smbios_slot_desc = 62, /* smbios_slot_desc */
YYSYMBOL_fw_config_table = 63, /* fw_config_table */
YYSYMBOL_fw_config_table_children = 64, /* fw_config_table_children */
YYSYMBOL_fw_config_field_children = 65, /* fw_config_field_children */
YYSYMBOL_fw_config_field = 66, /* fw_config_field */
YYSYMBOL_67_4 = 67, /* $@4 */
YYSYMBOL_68_5 = 68, /* $@5 */
YYSYMBOL_69_6 = 69, /* $@6 */
YYSYMBOL_fw_config_option = 70, /* fw_config_option */
YYSYMBOL_fw_config_probe = 71 /* fw_config_probe */
};
typedef enum yysymbol_kind_t yysymbol_kind_t;
#ifdef short
# undef short
#endif
/* On compilers that do not define __PTRDIFF_MAX__ etc., make sure
<limits.h> and (if available) <stdint.h> are included
so that the code can choose integer types of a good width. */
#ifndef __PTRDIFF_MAX__
# include <limits.h> /* INFRINGES ON USER NAME SPACE */
# if defined __STDC_VERSION__ && 199901 <= __STDC_VERSION__
# include <stdint.h> /* INFRINGES ON USER NAME SPACE */
# define YY_STDINT_H
# endif
#endif
/* Narrow types that promote to a signed type and that can represent a
signed or unsigned integer of at least N bits. In tables they can
save space and decrease cache pressure. Promoting to a signed type
helps avoid bugs in integer arithmetic. */
#ifdef __INT_LEAST8_MAX__
typedef __INT_LEAST8_TYPE__ yytype_int8;
#elif defined YY_STDINT_H
typedef int_least8_t yytype_int8;
#else
typedef signed char yytype_int8;
#endif
#ifdef __INT_LEAST16_MAX__
typedef __INT_LEAST16_TYPE__ yytype_int16;
#elif defined YY_STDINT_H
typedef int_least16_t yytype_int16;
#else
typedef short yytype_int16;
#endif
#if defined __UINT_LEAST8_MAX__ && __UINT_LEAST8_MAX__ <= __INT_MAX__
typedef __UINT_LEAST8_TYPE__ yytype_uint8;
#elif (!defined __UINT_LEAST8_MAX__ && defined YY_STDINT_H \
&& UINT_LEAST8_MAX <= INT_MAX)
typedef uint_least8_t yytype_uint8;
#elif !defined __UINT_LEAST8_MAX__ && UCHAR_MAX <= INT_MAX
typedef unsigned char yytype_uint8;
#else
typedef short yytype_uint8;
#endif
#if defined __UINT_LEAST16_MAX__ && __UINT_LEAST16_MAX__ <= __INT_MAX__
typedef __UINT_LEAST16_TYPE__ yytype_uint16;
#elif (!defined __UINT_LEAST16_MAX__ && defined YY_STDINT_H \
&& UINT_LEAST16_MAX <= INT_MAX)
typedef uint_least16_t yytype_uint16;
#elif !defined __UINT_LEAST16_MAX__ && USHRT_MAX <= INT_MAX
typedef unsigned short yytype_uint16;
#else
typedef int yytype_uint16;
#endif
#ifndef YYPTRDIFF_T
# if defined __PTRDIFF_TYPE__ && defined __PTRDIFF_MAX__
# define YYPTRDIFF_T __PTRDIFF_TYPE__
# define YYPTRDIFF_MAXIMUM __PTRDIFF_MAX__
# elif defined PTRDIFF_MAX
# ifndef ptrdiff_t
# include <stddef.h> /* INFRINGES ON USER NAME SPACE */
# endif
# define YYPTRDIFF_T ptrdiff_t
# define YYPTRDIFF_MAXIMUM PTRDIFF_MAX
# else
# define YYPTRDIFF_T long
# define YYPTRDIFF_MAXIMUM LONG_MAX
# endif
#endif
#ifndef YYSIZE_T
# ifdef __SIZE_TYPE__
# define YYSIZE_T __SIZE_TYPE__
# elif defined size_t
# define YYSIZE_T size_t
# elif defined __STDC_VERSION__ && 199901 <= __STDC_VERSION__
# include <stddef.h> /* INFRINGES ON USER NAME SPACE */
# define YYSIZE_T size_t
# else
# define YYSIZE_T unsigned
# endif
#endif
#define YYSIZE_MAXIMUM \
YY_CAST (YYPTRDIFF_T, \
(YYPTRDIFF_MAXIMUM < YY_CAST (YYSIZE_T, -1) \
? YYPTRDIFF_MAXIMUM \
: YY_CAST (YYSIZE_T, -1)))
#define YYSIZEOF(X) YY_CAST (YYPTRDIFF_T, sizeof (X))
/* Stored state numbers (used for stacks). */
typedef yytype_int8 yy_state_t;
/* State numbers in computations. */
typedef int yy_state_fast_t;
#ifndef YY_
# if defined YYENABLE_NLS && YYENABLE_NLS
# if ENABLE_NLS
# include <libintl.h> /* INFRINGES ON USER NAME SPACE */
# define YY_(Msgid) dgettext ("bison-runtime", Msgid)
# endif
# endif
# ifndef YY_
# define YY_(Msgid) Msgid
# endif
#endif
#ifndef YY_ATTRIBUTE_PURE
# if defined __GNUC__ && 2 < __GNUC__ + (96 <= __GNUC_MINOR__)
# define YY_ATTRIBUTE_PURE __attribute__ ((__pure__))
# else
# define YY_ATTRIBUTE_PURE
# endif
#endif
#ifndef YY_ATTRIBUTE_UNUSED
# if defined __GNUC__ && 2 < __GNUC__ + (7 <= __GNUC_MINOR__)
# define YY_ATTRIBUTE_UNUSED __attribute__ ((__unused__))
# else
# define YY_ATTRIBUTE_UNUSED
# endif
#endif
/* Suppress unused-variable warnings by "using" E. */
#if ! defined lint || defined __GNUC__
# define YYUSE(E) ((void) (E))
#else
# define YYUSE(E) /* empty */
#endif
#if defined __GNUC__ && ! defined __ICC && 407 <= __GNUC__ * 100 + __GNUC_MINOR__
/* Suppress an incorrect diagnostic about yylval being uninitialized. */
# define YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN \
_Pragma ("GCC diagnostic push") \
_Pragma ("GCC diagnostic ignored \"-Wuninitialized\"") \
_Pragma ("GCC diagnostic ignored \"-Wmaybe-uninitialized\"")
# define YY_IGNORE_MAYBE_UNINITIALIZED_END \
_Pragma ("GCC diagnostic pop")
#else
# define YY_INITIAL_VALUE(Value) Value
#endif
#ifndef YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN
# define YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN
# define YY_IGNORE_MAYBE_UNINITIALIZED_END
#endif
#ifndef YY_INITIAL_VALUE
# define YY_INITIAL_VALUE(Value) /* Nothing. */
#endif
#if defined __cplusplus && defined __GNUC__ && ! defined __ICC && 6 <= __GNUC__
# define YY_IGNORE_USELESS_CAST_BEGIN \
_Pragma ("GCC diagnostic push") \
_Pragma ("GCC diagnostic ignored \"-Wuseless-cast\"")
# define YY_IGNORE_USELESS_CAST_END \
_Pragma ("GCC diagnostic pop")
#endif
#ifndef YY_IGNORE_USELESS_CAST_BEGIN
# define YY_IGNORE_USELESS_CAST_BEGIN
# define YY_IGNORE_USELESS_CAST_END
#endif
#define YY_ASSERT(E) ((void) (0 && (E)))
#if !defined yyoverflow
/* The parser invokes alloca or malloc; define the necessary symbols. */
# ifdef YYSTACK_USE_ALLOCA
# if YYSTACK_USE_ALLOCA
# ifdef __GNUC__
# define YYSTACK_ALLOC __builtin_alloca
# elif defined __BUILTIN_VA_ARG_INCR
# include <alloca.h> /* INFRINGES ON USER NAME SPACE */
# elif defined _AIX
# define YYSTACK_ALLOC __alloca
# elif defined _MSC_VER
# include <malloc.h> /* INFRINGES ON USER NAME SPACE */
# define alloca _alloca
# else
# define YYSTACK_ALLOC alloca
# if ! defined _ALLOCA_H && ! defined EXIT_SUCCESS
# include <stdlib.h> /* INFRINGES ON USER NAME SPACE */
/* Use EXIT_SUCCESS as a witness for stdlib.h. */
# ifndef EXIT_SUCCESS
# define EXIT_SUCCESS 0
# endif
# endif
# endif
# endif
# endif
# ifdef YYSTACK_ALLOC
/* Pacify GCC's 'empty if-body' warning. */
# define YYSTACK_FREE(Ptr) do { /* empty */; } while (0)
# ifndef YYSTACK_ALLOC_MAXIMUM
/* The OS might guarantee only one guard page at the bottom of the stack,
and a page size can be as small as 4096 bytes. So we cannot safely
invoke alloca (N) if N exceeds 4096. Use a slightly smaller number
to allow for a few compiler-allocated temporary stack slots. */
# define YYSTACK_ALLOC_MAXIMUM 4032 /* reasonable circa 2006 */
# endif
# else
# define YYSTACK_ALLOC YYMALLOC
# define YYSTACK_FREE YYFREE
# ifndef YYSTACK_ALLOC_MAXIMUM
# define YYSTACK_ALLOC_MAXIMUM YYSIZE_MAXIMUM
# endif
# if (defined __cplusplus && ! defined EXIT_SUCCESS \
&& ! ((defined YYMALLOC || defined malloc) \
&& (defined YYFREE || defined free)))
# include <stdlib.h> /* INFRINGES ON USER NAME SPACE */
# ifndef EXIT_SUCCESS
# define EXIT_SUCCESS 0
# endif
# endif
# ifndef YYMALLOC
# define YYMALLOC malloc
# if ! defined malloc && ! defined EXIT_SUCCESS
void *malloc (YYSIZE_T); /* INFRINGES ON USER NAME SPACE */
# endif
# endif
# ifndef YYFREE
# define YYFREE free
# if ! defined free && ! defined EXIT_SUCCESS
void free (void *); /* INFRINGES ON USER NAME SPACE */
# endif
# endif
# endif
#endif /* !defined yyoverflow */
#if (! defined yyoverflow \
&& (! defined __cplusplus \
|| (defined YYSTYPE_IS_TRIVIAL && YYSTYPE_IS_TRIVIAL)))
/* A type that is properly aligned for any stack member. */
union yyalloc
{
yy_state_t yyss_alloc;
YYSTYPE yyvs_alloc;
};
/* The size of the maximum gap between one aligned stack and the next. */
# define YYSTACK_GAP_MAXIMUM (YYSIZEOF (union yyalloc) - 1)
/* The size of an array large to enough to hold all stacks, each with
N elements. */
# define YYSTACK_BYTES(N) \
((N) * (YYSIZEOF (yy_state_t) + YYSIZEOF (YYSTYPE)) \
+ YYSTACK_GAP_MAXIMUM)
# define YYCOPY_NEEDED 1
/* Relocate STACK from its old location to the new one. The
local variables YYSIZE and YYSTACKSIZE give the old and new number of
elements in the stack, and YYPTR gives the new location of the
stack. Advance YYPTR to a properly aligned location for the next
stack. */
# define YYSTACK_RELOCATE(Stack_alloc, Stack) \
do \
{ \
YYPTRDIFF_T yynewbytes; \
YYCOPY (&yyptr->Stack_alloc, Stack, yysize); \
Stack = &yyptr->Stack_alloc; \
yynewbytes = yystacksize * YYSIZEOF (*Stack) + YYSTACK_GAP_MAXIMUM; \
yyptr += yynewbytes / YYSIZEOF (*yyptr); \
} \
while (0)
#endif
#if defined YYCOPY_NEEDED && YYCOPY_NEEDED
/* Copy COUNT objects from SRC to DST. The source and destination do
not overlap. */
# ifndef YYCOPY
# if defined __GNUC__ && 1 < __GNUC__
# define YYCOPY(Dst, Src, Count) \
__builtin_memcpy (Dst, Src, YY_CAST (YYSIZE_T, (Count)) * sizeof (*(Src)))
# else
# define YYCOPY(Dst, Src, Count) \
do \
{ \
YYPTRDIFF_T yyi; \
for (yyi = 0; yyi < (Count); yyi++) \
(Dst)[yyi] = (Src)[yyi]; \
} \
while (0)
# endif
# endif
#endif /* !YYCOPY_NEEDED */
/* YYFINAL -- State number of the termination state. */
sconfig: Add support for firmware configuration This change adds support to sconfig for generating the firmware configuration field and option definitions in devicetree.cb. In addition these fields and options can be used to probe for a device and have that device be disabled if it is not found at boot time. New tokens: fw_config: top level token, table can be defined before chips field: define field in the mask with the start and end bits option: define option in a field with the value of the field probe: indicate that a device should probe by field and option Example: fw_config field FEATURE 0 0 option DISABLE 0 option ENABLE 1 end end chip drivers/generic/feature device generic 0 on probe FEATURE ENABLE end end Variants can add new fields and add new options to existing fields in overridetree.cb but cannot redefine an existing option. Devices can have multiple probe tokens, and the device will be considered to be found if any of them return true. The output from defining this field are: 1) the various fields and options will be added as macro constants to static.h and can be used by fw_config for probing. 2) the probe entries will result in a list of fields/options to probe that is added to the resulting struct device and handled by coreboot. BUG=b:147462631 Signed-off-by: Duncan Laurie <dlaurie@google.com> Change-Id: I8aea63e577d933aea09e0d0b09470929cc96e0de Reviewed-on: https://review.coreboot.org/c/coreboot/+/41440 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-05-16 00:39:08 +02:00
#define YYFINAL 2
/* YYLAST -- Last index in YYTABLE. */
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
#define YYLAST 79
/* YYNTOKENS -- Number of terminals. */
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
#define YYNTOKENS 46
/* YYNNTS -- Number of nonterminals. */
#define YYNNTS 26
/* YYNRULES -- Number of rules. */
#define YYNRULES 50
/* YYNSTATES -- Number of states. */
#define YYNSTATES 89
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
/* YYMAXUTOK -- Last valid token kind. */
#define YYMAXUTOK 300
/* YYTRANSLATE(TOKEN-NUM) -- Symbol number corresponding to TOKEN-NUM
as returned by yylex, with out-of-bounds checking. */
#define YYTRANSLATE(YYX) \
(0 <= (YYX) && (YYX) <= YYMAXUTOK \
? YY_CAST (yysymbol_kind_t, yytranslate[YYX]) \
: YYSYMBOL_YYUNDEF)
/* YYTRANSLATE[TOKEN-NUM] -- Symbol number corresponding to TOKEN-NUM
as returned by yylex. */
static const yytype_int8 yytranslate[] =
{
0, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 1, 2, 3, 4,
5, 6, 7, 8, 9, 10, 11, 12, 13, 14,
15, 16, 17, 18, 19, 20, 21, 22, 23, 24,
25, 26, 27, 28, 29, 30, 31, 32, 33, 34,
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
35, 36, 37, 38, 39, 40, 41, 42, 43, 44,
45
};
#if YYDEBUG
/* YYRLINE[YYN] -- Source line where rule number YYN was defined. */
static const yytype_int8 yyrline[] =
{
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
0, 25, 25, 25, 25, 27, 27, 27, 27, 27,
29, 29, 29, 29, 29, 29, 29, 29, 29, 31,
31, 40, 40, 48, 48, 56, 58, 62, 62, 64,
67, 70, 73, 76, 79, 82, 85, 88, 92, 95,
95, 98, 98, 101, 101, 107, 107, 113, 113, 119,
123
};
#endif
/** Accessing symbol of state STATE. */
#define YY_ACCESSING_SYMBOL(State) YY_CAST (yysymbol_kind_t, yystos[State])
#if YYDEBUG || 0
/* The user-facing name of the symbol whose (internal) number is
YYSYMBOL. No bounds checking. */
static const char *yysymbol_name (yysymbol_kind_t yysymbol) YY_ATTRIBUTE_UNUSED;
/* YYTNAME[SYMBOL-NUM] -- String name of the symbol SYMBOL-NUM.
First, the terminals, then, starting at YYNTOKENS, nonterminals. */
static const char *const yytname[] =
{
"\"end of file\"", "error", "\"invalid token\"", "CHIP", "DEVICE",
"REGISTER", "ALIAS", "REFERENCE", "ASSOCIATION", "BOOL", "STATUS",
"MANDATORY", "BUS", "RESOURCE", "END", "EQUALS", "HEX", "STRING", "PCI",
"PNP", "I2C", "APIC", "CPU_CLUSTER", "CPU", "DOMAIN", "IRQ", "DRQ",
"SLOT_DESC", "IO", "NUMBER", "SUBSYSTEMID", "INHERIT", "IOAPIC_IRQ",
"IOAPIC", "PCIINT", "GENERIC", "SPI", "USB", "MMIO", "LPC", "ESPI",
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
"GPIO", "FW_CONFIG_TABLE", "FW_CONFIG_FIELD", "FW_CONFIG_OPTION",
"FW_CONFIG_PROBE", "$accept", "devtree", "chipchildren",
"devicechildren", "chip", "@1", "device", "@2", "@3", "alias", "status",
"resource", "reference", "registers", "subsystemid", "ioapic_irq",
"smbios_slot_desc", "fw_config_table", "fw_config_table_children",
"fw_config_field_children", "fw_config_field", "$@4", "$@5", "$@6",
"fw_config_option", "fw_config_probe", YY_NULLPTR
};
static const char *
yysymbol_name (yysymbol_kind_t yysymbol)
{
return yytname[yysymbol];
}
#endif
#ifdef YYPRINT
/* YYTOKNUM[NUM] -- (External) token number corresponding to the
(internal) symbol number NUM (which must be that of a token). */
static const yytype_int16 yytoknum[] =
{
0, 256, 257, 258, 259, 260, 261, 262, 263, 264,
265, 266, 267, 268, 269, 270, 271, 272, 273, 274,
275, 276, 277, 278, 279, 280, 281, 282, 283, 284,
sconfig: Add support for firmware configuration This change adds support to sconfig for generating the firmware configuration field and option definitions in devicetree.cb. In addition these fields and options can be used to probe for a device and have that device be disabled if it is not found at boot time. New tokens: fw_config: top level token, table can be defined before chips field: define field in the mask with the start and end bits option: define option in a field with the value of the field probe: indicate that a device should probe by field and option Example: fw_config field FEATURE 0 0 option DISABLE 0 option ENABLE 1 end end chip drivers/generic/feature device generic 0 on probe FEATURE ENABLE end end Variants can add new fields and add new options to existing fields in overridetree.cb but cannot redefine an existing option. Devices can have multiple probe tokens, and the device will be considered to be found if any of them return true. The output from defining this field are: 1) the various fields and options will be added as macro constants to static.h and can be used by fw_config for probing. 2) the probe entries will result in a list of fields/options to probe that is added to the resulting struct device and handled by coreboot. BUG=b:147462631 Signed-off-by: Duncan Laurie <dlaurie@google.com> Change-Id: I8aea63e577d933aea09e0d0b09470929cc96e0de Reviewed-on: https://review.coreboot.org/c/coreboot/+/41440 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-05-16 00:39:08 +02:00
285, 286, 287, 288, 289, 290, 291, 292, 293, 294,
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
295, 296, 297, 298, 299, 300
};
#endif
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
#define YYPACT_NINF (-15)
#define yypact_value_is_default(Yyn) \
((Yyn) == YYPACT_NINF)
#define YYTABLE_NINF (-1)
#define yytable_value_is_error(Yyn) \
0
/* YYPACT[STATE-NUM] -- Index in YYTABLE of the portion describing
STATE-NUM. */
static const yytype_int8 yypact[] =
{
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
-15, 9, -15, 0, -15, -15, -15, -15, -11, -15,
-15, 2, -15, 45, -8, 13, 6, 19, -15, -15,
-15, -15, -15, 10, -15, 23, 12, 11, 36, -15,
-15, -7, 25, 39, 30, 37, -15, -6, -15, 38,
-15, -15, -15, -15, 40, 25, -15, -15, -1, -15,
24, -15, -15, -15, -15, -15, -3, -15, 27, -15,
41, 31, 32, 46, -15, -15, -15, -15, -15, -15,
-15, -15, 1, 47, 48, 35, 33, 49, -15, 42,
51, 43, 44, -15, -15, 52, -15, -15, -15
};
/* YYDEFACT[STATE-NUM] -- Default reduction number in state STATE-NUM.
Performed when YYTABLE does not specify something else to do. Zero
means the default is an error. */
static const yytype_int8 yydefact[] =
{
2, 0, 1, 0, 40, 3, 4, 19, 0, 9,
38, 0, 39, 0, 47, 0, 0, 0, 20, 6,
5, 8, 7, 45, 42, 0, 0, 0, 0, 43,
42, 0, 0, 25, 0, 0, 42, 0, 48, 0,
41, 27, 28, 23, 0, 0, 31, 30, 0, 46,
0, 18, 26, 21, 44, 49, 0, 18, 0, 24,
0, 0, 0, 0, 11, 10, 12, 16, 13, 14,
15, 17, 0, 0, 0, 0, 0, 0, 22, 0,
37, 32, 0, 50, 29, 36, 33, 34, 35
};
/* YYPGOTO[NTERM-NUM]. */
static const yytype_int8 yypgoto[] =
{
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
-15, -15, -15, 15, 17, -15, 57, -15, -15, -15,
34, -15, -15, 62, -15, -15, -15, -15, -15, -14,
-15, -15, -15, -15, -15, -15
};
/* YYDEFGOTO[NTERM-NUM]. */
static const yytype_int8 yydefgoto[] =
{
-1, 1, 13, 56, 64, 9, 65, 57, 51, 45,
43, 66, 21, 67, 68, 69, 70, 6, 8, 31,
12, 36, 30, 24, 40, 71
};
/* YYTABLE[YYPACT[STATE-NUM]] -- What to do in state STATE-NUM. If
positive, shift that token. If negative, reduce the rule whose
number is the opposite. If YYTABLE_NINF, syntax error. */
static const yytype_int8 yytable[] =
{
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
3, 15, 16, 10, 3, 15, 16, 38, 49, 2,
58, 59, 3, 54, 58, 78, 37, 7, 5, 14,
25, 23, 48, 27, 60, 26, 34, 61, 60, 62,
19, 61, 11, 62, 41, 42, 28, 39, 39, 29,
32, 33, 63, 39, 35, 44, 63, 46, 3, 15,
16, 4, 17, 55, 47, 50, 73, 52, 74, 18,
75, 76, 79, 77, 81, 80, 83, 82, 85, 88,
20, 84, 72, 87, 86, 22, 0, 0, 0, 53
};
static const yytype_int8 yycheck[] =
{
3, 4, 5, 14, 3, 4, 5, 14, 14, 0,
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
13, 14, 3, 14, 13, 14, 30, 17, 1, 17,
7, 29, 36, 17, 27, 12, 15, 30, 27, 32,
13, 30, 43, 32, 9, 10, 17, 44, 44, 29,
17, 29, 45, 44, 8, 6, 45, 17, 3, 4,
5, 42, 7, 29, 17, 17, 29, 17, 17, 14,
29, 29, 15, 17, 29, 17, 17, 34, 17, 17,
13, 29, 57, 29, 31, 13, -1, -1, -1, 45
};
/* YYSTOS[STATE-NUM] -- The (internal number of the) accessing
symbol of state STATE-NUM. */
static const yytype_int8 yystos[] =
{
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
0, 47, 0, 3, 42, 50, 63, 17, 64, 51,
14, 43, 66, 48, 17, 4, 5, 7, 14, 50,
52, 58, 59, 29, 69, 7, 12, 17, 17, 29,
68, 65, 17, 29, 15, 8, 67, 65, 14, 44,
70, 9, 10, 56, 6, 55, 17, 17, 65, 14,
17, 54, 17, 56, 14, 29, 49, 53, 13, 14,
27, 30, 32, 45, 50, 52, 57, 59, 60, 61,
62, 71, 49, 29, 17, 29, 29, 17, 14, 15,
17, 29, 34, 17, 29, 17, 31, 29, 17
};
/* YYR1[YYN] -- Symbol number of symbol that rule YYN derives. */
static const yytype_int8 yyr1[] =
{
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
0, 46, 47, 47, 47, 48, 48, 48, 48, 48,
49, 49, 49, 49, 49, 49, 49, 49, 49, 51,
50, 53, 52, 54, 52, 55, 55, 56, 56, 57,
58, 59, 60, 60, 61, 62, 62, 62, 63, 64,
64, 65, 65, 67, 66, 68, 66, 69, 66, 70,
71
};
/* YYR2[YYN] -- Number of symbols on the right hand side of rule YYN. */
static const yytype_int8 yyr2[] =
{
sconfig: Allow to link devices to other device's drivers Rarely, the driver of one device needs to know about another device that can be anywhere in the device hierarchy. Current applications boil down to EEPROMs that store information that is consumed by some code (e.g. MAC address). The idea is to give device nodes in the `devicetree.cb` an alias that can later be used to link it to a device driver's `config` structure. The driver has to declare a field of type `struct device *`, e.g. struct some_chip_driver_config { DEVTREE_CONST struct device *needed_eeprom; }; In the devicetree, the referenced device gets an alias, e.g. device i2c 0x50 alias my_eeprom on end The author of the devicetree is free to choose any alias name that is unique in the devicetree. Later, when configuring the driver the alias can be used to link the device with the field of a driver's config: chip some/chip/driver use my_eeprom as needed_eeprom end Override devices can add an alias if it does not exist, but cannot change the alias for a device that already exists. Alias names are checked for conflicts both in the base tree and in the override tree. References are resolved after the tree is parsed so aliases and references do not need to be in a specific order in the tree. Change-Id: I058a319f9b968924fbef9485a96c9e3f900a3ee8 Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/35456 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-06-03 19:20:07 +02:00
0, 2, 0, 2, 2, 2, 2, 2, 2, 0,
2, 2, 2, 2, 2, 2, 2, 2, 0, 0,
5, 0, 8, 0, 7, 0, 2, 1, 1, 4,
4, 4, 3, 4, 4, 5, 4, 3, 3, 2,
0, 2, 0, 0, 7, 0, 6, 0, 5, 3,
3
};
enum { YYENOMEM = -2 };
#define yyerrok (yyerrstatus = 0)
#define yyclearin (yychar = YYEMPTY)
#define YYACCEPT goto yyacceptlab
#define YYABORT goto yyabortlab
#define YYERROR goto yyerrorlab
#define YYRECOVERING() (!!yyerrstatus)
#define YYBACKUP(Token, Value) \
do \
if (yychar == YYEMPTY) \
{ \
yychar = (Token); \
yylval = (Value); \
YYPOPSTACK (yylen); \
yystate = *yyssp; \
goto yybackup; \
} \
else \
{ \
yyerror (YY_("syntax error: cannot back up")); \
YYERROR; \
} \
while (0)
/* Backward compatibility with an undocumented macro.
Use YYerror or YYUNDEF. */
#define YYERRCODE YYUNDEF
/* Enable debugging if requested. */
#if YYDEBUG
# ifndef YYFPRINTF
# include <stdio.h> /* INFRINGES ON USER NAME SPACE */
# define YYFPRINTF fprintf
# endif
# define YYDPRINTF(Args) \
do { \
if (yydebug) \
YYFPRINTF Args; \
} while (0)
/* This macro is provided for backward compatibility. */
# ifndef YY_LOCATION_PRINT
# define YY_LOCATION_PRINT(File, Loc) ((void) 0)
# endif
# define YY_SYMBOL_PRINT(Title, Kind, Value, Location) \
do { \
if (yydebug) \
{ \
YYFPRINTF (stderr, "%s ", Title); \
yy_symbol_print (stderr, \
Kind, Value); \
YYFPRINTF (stderr, "\n"); \
} \
} while (0)
/*-----------------------------------.
| Print this symbol's value on YYO. |
`-----------------------------------*/
static void
yy_symbol_value_print (FILE *yyo,
yysymbol_kind_t yykind, YYSTYPE const * const yyvaluep)
{
FILE *yyoutput = yyo;
YYUSE (yyoutput);
if (!yyvaluep)
return;
# ifdef YYPRINT
if (yykind < YYNTOKENS)
YYPRINT (yyo, yytoknum[yykind], *yyvaluep);
# endif
YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN
YYUSE (yykind);
YY_IGNORE_MAYBE_UNINITIALIZED_END
}
/*---------------------------.
| Print this symbol on YYO. |
`---------------------------*/
static void
yy_symbol_print (FILE *yyo,
yysymbol_kind_t yykind, YYSTYPE const * const yyvaluep)
{
YYFPRINTF (yyo, "%s %s (",
yykind < YYNTOKENS ? "token" : "nterm", yysymbol_name (yykind));
yy_symbol_value_print (yyo, yykind, yyvaluep);
YYFPRINTF (yyo, ")");
}
/*------------------------------------------------------------------.
| yy_stack_print -- Print the state stack from its BOTTOM up to its |
| TOP (included). |
`------------------------------------------------------------------*/
static void
yy_stack_print (yy_state_t *yybottom, yy_state_t *yytop)
{
YYFPRINTF (stderr, "Stack now");
for (; yybottom <= yytop; yybottom++)
{
int yybot = *yybottom;
YYFPRINTF (stderr, " %d", yybot);
}
YYFPRINTF (stderr, "\n");
}
# define YY_STACK_PRINT(Bottom, Top) \
do { \
if (yydebug) \
yy_stack_print ((Bottom), (Top)); \
} while (0)
/*------------------------------------------------.
| Report that the YYRULE is going to be reduced. |
`------------------------------------------------*/
static void
yy_reduce_print (yy_state_t *yyssp, YYSTYPE *yyvsp,
int yyrule)
{
int yylno = yyrline[yyrule];
int yynrhs = yyr2[yyrule];
int yyi;
YYFPRINTF (stderr, "Reducing stack by rule %d (line %d):\n",
yyrule - 1, yylno);
/* The symbols being reduced. */
for (yyi = 0; yyi < yynrhs; yyi++)
{
YYFPRINTF (stderr, " $%d = ", yyi + 1);
yy_symbol_print (stderr,
YY_ACCESSING_SYMBOL (+yyssp[yyi + 1 - yynrhs]),
&yyvsp[(yyi + 1) - (yynrhs)]);
YYFPRINTF (stderr, "\n");
}
}
# define YY_REDUCE_PRINT(Rule) \
do { \
if (yydebug) \
yy_reduce_print (yyssp, yyvsp, Rule); \
} while (0)
/* Nonzero means print parse trace. It is left uninitialized so that
multiple parsers can coexist. */
int yydebug;
#else /* !YYDEBUG */
# define YYDPRINTF(Args) ((void) 0)
# define YY_SYMBOL_PRINT(Title, Kind, Value, Location)
# define YY_STACK_PRINT(Bottom, Top)
# define YY_REDUCE_PRINT(Rule)
#endif /* !YYDEBUG */
/* YYINITDEPTH -- initial size of the parser's stacks. */
#ifndef YYINITDEPTH
# define YYINITDEPTH 200
#endif
/* YYMAXDEPTH -- maximum size the stacks can grow to (effective only
if the built-in stack extension method is used).
Do not make this value too large; the results are undefined if
YYSTACK_ALLOC_MAXIMUM < YYSTACK_BYTES (YYMAXDEPTH)
evaluated with infinite-precision integer arithmetic. */
#ifndef YYMAXDEPTH
# define YYMAXDEPTH 10000
#endif
/*-----------------------------------------------.
| Release the memory associated to this symbol. |
`-----------------------------------------------*/
static void
yydestruct (const char *yymsg,
yysymbol_kind_t yykind, YYSTYPE *yyvaluep)
{
YYUSE (yyvaluep);
if (!yymsg)
yymsg = "Deleting";
YY_SYMBOL_PRINT (yymsg, yykind, yyvaluep, yylocationp);
YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN
YYUSE (yykind);
YY_IGNORE_MAYBE_UNINITIALIZED_END
}
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
/* Lookahead token kind. */
int yychar;
/* The semantic value of the lookahead symbol. */
YYSTYPE yylval;
/* Number of syntax errors so far. */
int yynerrs;
/*----------.
| yyparse. |
`----------*/
int
yyparse (void)
{
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
yy_state_fast_t yystate = 0;
/* Number of tokens to shift before error messages enabled. */
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
int yyerrstatus = 0;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
/* Refer to the stacks through separate pointers, to allow yyoverflow
to reallocate them elsewhere. */
/* Their size. */
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
YYPTRDIFF_T yystacksize = YYINITDEPTH;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
/* The state stack: array, bottom, top. */
yy_state_t yyssa[YYINITDEPTH];
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
yy_state_t *yyss = yyssa;
yy_state_t *yyssp = yyss;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
/* The semantic value stack: array, bottom, top. */
YYSTYPE yyvsa[YYINITDEPTH];
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
YYSTYPE *yyvs = yyvsa;
YYSTYPE *yyvsp = yyvs;
int yyn;
/* The return value of yyparse. */
int yyresult;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
/* Lookahead symbol kind. */
yysymbol_kind_t yytoken = YYSYMBOL_YYEMPTY;
/* The variables used to return semantic value and location from the
action routines. */
YYSTYPE yyval;
#define YYPOPSTACK(N) (yyvsp -= (N), yyssp -= (N))
/* The number of symbols on the RHS of the reduced rule.
Keep to zero when no symbol should be popped. */
int yylen = 0;
YYDPRINTF ((stderr, "Starting parse\n"));
yychar = YYEMPTY; /* Cause a token to be read. */
goto yysetstate;
/*------------------------------------------------------------.
| yynewstate -- push a new state, which is found in yystate. |
`------------------------------------------------------------*/
yynewstate:
/* In all cases, when you get here, the value and location stacks
have just been pushed. So pushing a state here evens the stacks. */
yyssp++;
/*--------------------------------------------------------------------.
| yysetstate -- set current state (the top of the stack) to yystate. |
`--------------------------------------------------------------------*/
yysetstate:
YYDPRINTF ((stderr, "Entering state %d\n", yystate));
YY_ASSERT (0 <= yystate && yystate < YYNSTATES);
YY_IGNORE_USELESS_CAST_BEGIN
*yyssp = YY_CAST (yy_state_t, yystate);
YY_IGNORE_USELESS_CAST_END
YY_STACK_PRINT (yyss, yyssp);
if (yyss + yystacksize - 1 <= yyssp)
#if !defined yyoverflow && !defined YYSTACK_RELOCATE
goto yyexhaustedlab;
#else
{
/* Get the current used size of the three stacks, in elements. */
YYPTRDIFF_T yysize = yyssp - yyss + 1;
# if defined yyoverflow
{
/* Give user a chance to reallocate the stack. Use copies of
these so that the &'s don't force the real ones into
memory. */
yy_state_t *yyss1 = yyss;
YYSTYPE *yyvs1 = yyvs;
/* Each stack pointer address is followed by the size of the
data in use in that stack, in bytes. This used to be a
conditional around just the two extra args, but that might
be undefined if yyoverflow is a macro. */
yyoverflow (YY_("memory exhausted"),
&yyss1, yysize * YYSIZEOF (*yyssp),
&yyvs1, yysize * YYSIZEOF (*yyvsp),
&yystacksize);
yyss = yyss1;
yyvs = yyvs1;
}
# else /* defined YYSTACK_RELOCATE */
/* Extend the stack our own way. */
if (YYMAXDEPTH <= yystacksize)
goto yyexhaustedlab;
yystacksize *= 2;
if (YYMAXDEPTH < yystacksize)
yystacksize = YYMAXDEPTH;
{
yy_state_t *yyss1 = yyss;
union yyalloc *yyptr =
YY_CAST (union yyalloc *,
YYSTACK_ALLOC (YY_CAST (YYSIZE_T, YYSTACK_BYTES (yystacksize))));
if (! yyptr)
goto yyexhaustedlab;
YYSTACK_RELOCATE (yyss_alloc, yyss);
YYSTACK_RELOCATE (yyvs_alloc, yyvs);
# undef YYSTACK_RELOCATE
if (yyss1 != yyssa)
YYSTACK_FREE (yyss1);
}
# endif
yyssp = yyss + yysize - 1;
yyvsp = yyvs + yysize - 1;
YY_IGNORE_USELESS_CAST_BEGIN
YYDPRINTF ((stderr, "Stack size increased to %ld\n",
YY_CAST (long, yystacksize)));
YY_IGNORE_USELESS_CAST_END
if (yyss + yystacksize - 1 <= yyssp)
YYABORT;
}
#endif /* !defined yyoverflow && !defined YYSTACK_RELOCATE */
if (yystate == YYFINAL)
YYACCEPT;
goto yybackup;
/*-----------.
| yybackup. |
`-----------*/
yybackup:
/* Do appropriate processing given the current state. Read a
lookahead token if we need one and don't already have one. */
/* First try to decide what to do without reference to lookahead token. */
yyn = yypact[yystate];
if (yypact_value_is_default (yyn))
goto yydefault;
/* Not known => get a lookahead token if don't already have one. */
/* YYCHAR is either empty, or end-of-input, or a valid lookahead. */
if (yychar == YYEMPTY)
{
YYDPRINTF ((stderr, "Reading a token\n"));
yychar = yylex ();
}
if (yychar <= YYEOF)
{
yychar = YYEOF;
yytoken = YYSYMBOL_YYEOF;
YYDPRINTF ((stderr, "Now at end of input.\n"));
}
else if (yychar == YYerror)
{
/* The scanner already issued an error message, process directly
to error recovery. But do not keep the error token as
lookahead, it is too special and may lead us to an endless
loop in error recovery. */
yychar = YYUNDEF;
yytoken = YYSYMBOL_YYerror;
goto yyerrlab1;
}
else
{
yytoken = YYTRANSLATE (yychar);
YY_SYMBOL_PRINT ("Next token is", yytoken, &yylval, &yylloc);
}
/* If the proper action on seeing token YYTOKEN is to reduce or to
detect an error, take that action. */
yyn += yytoken;
if (yyn < 0 || YYLAST < yyn || yycheck[yyn] != yytoken)
goto yydefault;
yyn = yytable[yyn];
if (yyn <= 0)
{
if (yytable_value_is_error (yyn))
goto yyerrlab;
yyn = -yyn;
goto yyreduce;
}
/* Count tokens shifted since error; after three, turn off error
status. */
if (yyerrstatus)
yyerrstatus--;
/* Shift the lookahead token. */
YY_SYMBOL_PRINT ("Shifting", yytoken, &yylval, &yylloc);
yystate = yyn;
YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN
*++yyvsp = yylval;
YY_IGNORE_MAYBE_UNINITIALIZED_END
/* Discard the shifted token. */
yychar = YYEMPTY;
goto yynewstate;
/*-----------------------------------------------------------.
| yydefault -- do the default action for the current state. |
`-----------------------------------------------------------*/
yydefault:
yyn = yydefact[yystate];
if (yyn == 0)
goto yyerrlab;
goto yyreduce;
/*-----------------------------.
| yyreduce -- do a reduction. |
`-----------------------------*/
yyreduce:
/* yyn is the number of a rule to reduce with. */
yylen = yyr2[yyn];
/* If YYLEN is nonzero, implement the default value of the action:
'$$ = $1'.
Otherwise, the following line sets YYVAL to garbage.
This behavior is undocumented and Bison
users should not rely upon it. Assigning to YYVAL
unconditionally makes the parser a bit smaller, and it avoids a
GCC warning that YYVAL may be used uninitialized. */
yyval = yyvsp[1-yylen];
YY_REDUCE_PRINT (yyn);
switch (yyn)
{
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 2: /* devtree: %empty */
{ cur_parent = root_parent; }
break;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 19: /* @1: %empty */
{
(yyval.chip_instance) = new_chip_instance((yyvsp[0].string));
chip_enqueue_tail(cur_chip_instance);
cur_chip_instance = (yyval.chip_instance);
}
break;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 20: /* chip: CHIP STRING @1 chipchildren END */
{
cur_chip_instance = chip_dequeue_tail();
}
break;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 21: /* @2: %empty */
sconfig: Allow to link devices to other device's drivers Rarely, the driver of one device needs to know about another device that can be anywhere in the device hierarchy. Current applications boil down to EEPROMs that store information that is consumed by some code (e.g. MAC address). The idea is to give device nodes in the `devicetree.cb` an alias that can later be used to link it to a device driver's `config` structure. The driver has to declare a field of type `struct device *`, e.g. struct some_chip_driver_config { DEVTREE_CONST struct device *needed_eeprom; }; In the devicetree, the referenced device gets an alias, e.g. device i2c 0x50 alias my_eeprom on end The author of the devicetree is free to choose any alias name that is unique in the devicetree. Later, when configuring the driver the alias can be used to link the device with the field of a driver's config: chip some/chip/driver use my_eeprom as needed_eeprom end Override devices can add an alias if it does not exist, but cannot change the alias for a device that already exists. Alias names are checked for conflicts both in the base tree and in the override tree. References are resolved after the tree is parsed so aliases and references do not need to be in a specific order in the tree. Change-Id: I058a319f9b968924fbef9485a96c9e3f900a3ee8 Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/35456 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-06-03 19:20:07 +02:00
{
(yyval.dev) = new_device_raw(cur_parent, cur_chip_instance, (yyvsp[-3].number), (yyvsp[-2].string), (yyvsp[-1].string), (yyvsp[0].number));
cur_parent = (yyval.dev)->last_bus;
}
break;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 22: /* device: DEVICE BUS NUMBER alias status @2 devicechildren END */
{
cur_parent = (yyvsp[-2].dev)->parent;
}
break;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 23: /* @3: %empty */
{
(yyval.dev) = new_device_reference(cur_parent, cur_chip_instance, (yyvsp[-1].string), (yyvsp[0].number));
cur_parent = (yyval.dev)->last_bus;
}
break;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 24: /* device: DEVICE REFERENCE STRING status @3 devicechildren END */
{
cur_parent = (yyvsp[-2].dev)->parent;
}
break;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 25: /* alias: %empty */
sconfig: Allow to link devices to other device's drivers Rarely, the driver of one device needs to know about another device that can be anywhere in the device hierarchy. Current applications boil down to EEPROMs that store information that is consumed by some code (e.g. MAC address). The idea is to give device nodes in the `devicetree.cb` an alias that can later be used to link it to a device driver's `config` structure. The driver has to declare a field of type `struct device *`, e.g. struct some_chip_driver_config { DEVTREE_CONST struct device *needed_eeprom; }; In the devicetree, the referenced device gets an alias, e.g. device i2c 0x50 alias my_eeprom on end The author of the devicetree is free to choose any alias name that is unique in the devicetree. Later, when configuring the driver the alias can be used to link the device with the field of a driver's config: chip some/chip/driver use my_eeprom as needed_eeprom end Override devices can add an alias if it does not exist, but cannot change the alias for a device that already exists. Alias names are checked for conflicts both in the base tree and in the override tree. References are resolved after the tree is parsed so aliases and references do not need to be in a specific order in the tree. Change-Id: I058a319f9b968924fbef9485a96c9e3f900a3ee8 Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/35456 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-06-03 19:20:07 +02:00
{
(yyval.string) = NULL;
}
break;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 26: /* alias: ALIAS STRING */
sconfig: Allow to link devices to other device's drivers Rarely, the driver of one device needs to know about another device that can be anywhere in the device hierarchy. Current applications boil down to EEPROMs that store information that is consumed by some code (e.g. MAC address). The idea is to give device nodes in the `devicetree.cb` an alias that can later be used to link it to a device driver's `config` structure. The driver has to declare a field of type `struct device *`, e.g. struct some_chip_driver_config { DEVTREE_CONST struct device *needed_eeprom; }; In the devicetree, the referenced device gets an alias, e.g. device i2c 0x50 alias my_eeprom on end The author of the devicetree is free to choose any alias name that is unique in the devicetree. Later, when configuring the driver the alias can be used to link the device with the field of a driver's config: chip some/chip/driver use my_eeprom as needed_eeprom end Override devices can add an alias if it does not exist, but cannot change the alias for a device that already exists. Alias names are checked for conflicts both in the base tree and in the override tree. References are resolved after the tree is parsed so aliases and references do not need to be in a specific order in the tree. Change-Id: I058a319f9b968924fbef9485a96c9e3f900a3ee8 Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/35456 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-06-03 19:20:07 +02:00
{
(yyval.string) = (yyvsp[0].string);
}
break;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 29: /* resource: RESOURCE NUMBER EQUALS NUMBER */
{ add_resource(cur_parent, (yyvsp[-3].number), strtol((yyvsp[-2].string), NULL, 0), strtol((yyvsp[0].string), NULL, 0)); }
break;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 30: /* reference: REFERENCE STRING ASSOCIATION STRING */
sconfig: Allow to link devices to other device's drivers Rarely, the driver of one device needs to know about another device that can be anywhere in the device hierarchy. Current applications boil down to EEPROMs that store information that is consumed by some code (e.g. MAC address). The idea is to give device nodes in the `devicetree.cb` an alias that can later be used to link it to a device driver's `config` structure. The driver has to declare a field of type `struct device *`, e.g. struct some_chip_driver_config { DEVTREE_CONST struct device *needed_eeprom; }; In the devicetree, the referenced device gets an alias, e.g. device i2c 0x50 alias my_eeprom on end The author of the devicetree is free to choose any alias name that is unique in the devicetree. Later, when configuring the driver the alias can be used to link the device with the field of a driver's config: chip some/chip/driver use my_eeprom as needed_eeprom end Override devices can add an alias if it does not exist, but cannot change the alias for a device that already exists. Alias names are checked for conflicts both in the base tree and in the override tree. References are resolved after the tree is parsed so aliases and references do not need to be in a specific order in the tree. Change-Id: I058a319f9b968924fbef9485a96c9e3f900a3ee8 Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/35456 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-06-03 19:20:07 +02:00
{ add_reference(cur_chip_instance, (yyvsp[0].string), (yyvsp[-2].string)); }
break;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 31: /* registers: REGISTER STRING EQUALS STRING */
{ add_register(cur_chip_instance, (yyvsp[-2].string), (yyvsp[0].string)); }
break;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 32: /* subsystemid: SUBSYSTEMID NUMBER NUMBER */
{ add_pci_subsystem_ids(cur_parent, strtol((yyvsp[-1].string), NULL, 16), strtol((yyvsp[0].string), NULL, 16), 0); }
break;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 33: /* subsystemid: SUBSYSTEMID NUMBER NUMBER INHERIT */
{ add_pci_subsystem_ids(cur_parent, strtol((yyvsp[-2].string), NULL, 16), strtol((yyvsp[-1].string), NULL, 16), 1); }
break;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 34: /* ioapic_irq: IOAPIC_IRQ NUMBER PCIINT NUMBER */
{ add_ioapic_info(cur_parent, strtol((yyvsp[-2].string), NULL, 16), (yyvsp[-1].string), strtol((yyvsp[0].string), NULL, 16)); }
break;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 35: /* smbios_slot_desc: SLOT_DESC STRING STRING STRING STRING */
{ add_slot_desc(cur_parent, (yyvsp[-3].string), (yyvsp[-2].string), (yyvsp[-1].string), (yyvsp[0].string)); }
break;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 36: /* smbios_slot_desc: SLOT_DESC STRING STRING STRING */
{ add_slot_desc(cur_parent, (yyvsp[-2].string), (yyvsp[-1].string), (yyvsp[0].string), NULL); }
break;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 37: /* smbios_slot_desc: SLOT_DESC STRING STRING */
{ add_slot_desc(cur_parent, (yyvsp[-1].string), (yyvsp[0].string), NULL, NULL); }
break;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 38: /* fw_config_table: FW_CONFIG_TABLE fw_config_table_children END */
sconfig: Add support for firmware configuration This change adds support to sconfig for generating the firmware configuration field and option definitions in devicetree.cb. In addition these fields and options can be used to probe for a device and have that device be disabled if it is not found at boot time. New tokens: fw_config: top level token, table can be defined before chips field: define field in the mask with the start and end bits option: define option in a field with the value of the field probe: indicate that a device should probe by field and option Example: fw_config field FEATURE 0 0 option DISABLE 0 option ENABLE 1 end end chip drivers/generic/feature device generic 0 on probe FEATURE ENABLE end end Variants can add new fields and add new options to existing fields in overridetree.cb but cannot redefine an existing option. Devices can have multiple probe tokens, and the device will be considered to be found if any of them return true. The output from defining this field are: 1) the various fields and options will be added as macro constants to static.h and can be used by fw_config for probing. 2) the probe entries will result in a list of fields/options to probe that is added to the resulting struct device and handled by coreboot. BUG=b:147462631 Signed-off-by: Duncan Laurie <dlaurie@google.com> Change-Id: I8aea63e577d933aea09e0d0b09470929cc96e0de Reviewed-on: https://review.coreboot.org/c/coreboot/+/41440 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-05-16 00:39:08 +02:00
{ }
break;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 43: /* $@4: %empty */
sconfig: Add support for firmware configuration This change adds support to sconfig for generating the firmware configuration field and option definitions in devicetree.cb. In addition these fields and options can be used to probe for a device and have that device be disabled if it is not found at boot time. New tokens: fw_config: top level token, table can be defined before chips field: define field in the mask with the start and end bits option: define option in a field with the value of the field probe: indicate that a device should probe by field and option Example: fw_config field FEATURE 0 0 option DISABLE 0 option ENABLE 1 end end chip drivers/generic/feature device generic 0 on probe FEATURE ENABLE end end Variants can add new fields and add new options to existing fields in overridetree.cb but cannot redefine an existing option. Devices can have multiple probe tokens, and the device will be considered to be found if any of them return true. The output from defining this field are: 1) the various fields and options will be added as macro constants to static.h and can be used by fw_config for probing. 2) the probe entries will result in a list of fields/options to probe that is added to the resulting struct device and handled by coreboot. BUG=b:147462631 Signed-off-by: Duncan Laurie <dlaurie@google.com> Change-Id: I8aea63e577d933aea09e0d0b09470929cc96e0de Reviewed-on: https://review.coreboot.org/c/coreboot/+/41440 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-05-16 00:39:08 +02:00
{
cur_field = new_fw_config_field((yyvsp[-2].string), strtoul((yyvsp[-1].string), NULL, 0), strtoul((yyvsp[0].string), NULL, 0));
}
break;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 44: /* fw_config_field: FW_CONFIG_FIELD STRING NUMBER NUMBER $@4 fw_config_field_children END */
sconfig: Add support for firmware configuration This change adds support to sconfig for generating the firmware configuration field and option definitions in devicetree.cb. In addition these fields and options can be used to probe for a device and have that device be disabled if it is not found at boot time. New tokens: fw_config: top level token, table can be defined before chips field: define field in the mask with the start and end bits option: define option in a field with the value of the field probe: indicate that a device should probe by field and option Example: fw_config field FEATURE 0 0 option DISABLE 0 option ENABLE 1 end end chip drivers/generic/feature device generic 0 on probe FEATURE ENABLE end end Variants can add new fields and add new options to existing fields in overridetree.cb but cannot redefine an existing option. Devices can have multiple probe tokens, and the device will be considered to be found if any of them return true. The output from defining this field are: 1) the various fields and options will be added as macro constants to static.h and can be used by fw_config for probing. 2) the probe entries will result in a list of fields/options to probe that is added to the resulting struct device and handled by coreboot. BUG=b:147462631 Signed-off-by: Duncan Laurie <dlaurie@google.com> Change-Id: I8aea63e577d933aea09e0d0b09470929cc96e0de Reviewed-on: https://review.coreboot.org/c/coreboot/+/41440 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-05-16 00:39:08 +02:00
{ }
break;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 45: /* $@5: %empty */
sconfig: Add support for firmware configuration This change adds support to sconfig for generating the firmware configuration field and option definitions in devicetree.cb. In addition these fields and options can be used to probe for a device and have that device be disabled if it is not found at boot time. New tokens: fw_config: top level token, table can be defined before chips field: define field in the mask with the start and end bits option: define option in a field with the value of the field probe: indicate that a device should probe by field and option Example: fw_config field FEATURE 0 0 option DISABLE 0 option ENABLE 1 end end chip drivers/generic/feature device generic 0 on probe FEATURE ENABLE end end Variants can add new fields and add new options to existing fields in overridetree.cb but cannot redefine an existing option. Devices can have multiple probe tokens, and the device will be considered to be found if any of them return true. The output from defining this field are: 1) the various fields and options will be added as macro constants to static.h and can be used by fw_config for probing. 2) the probe entries will result in a list of fields/options to probe that is added to the resulting struct device and handled by coreboot. BUG=b:147462631 Signed-off-by: Duncan Laurie <dlaurie@google.com> Change-Id: I8aea63e577d933aea09e0d0b09470929cc96e0de Reviewed-on: https://review.coreboot.org/c/coreboot/+/41440 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-05-16 00:39:08 +02:00
{
cur_field = new_fw_config_field((yyvsp[-1].string), strtoul((yyvsp[0].string), NULL, 0), strtoul((yyvsp[0].string), NULL, 0));
}
break;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 46: /* fw_config_field: FW_CONFIG_FIELD STRING NUMBER $@5 fw_config_field_children END */
sconfig: Add support for firmware configuration This change adds support to sconfig for generating the firmware configuration field and option definitions in devicetree.cb. In addition these fields and options can be used to probe for a device and have that device be disabled if it is not found at boot time. New tokens: fw_config: top level token, table can be defined before chips field: define field in the mask with the start and end bits option: define option in a field with the value of the field probe: indicate that a device should probe by field and option Example: fw_config field FEATURE 0 0 option DISABLE 0 option ENABLE 1 end end chip drivers/generic/feature device generic 0 on probe FEATURE ENABLE end end Variants can add new fields and add new options to existing fields in overridetree.cb but cannot redefine an existing option. Devices can have multiple probe tokens, and the device will be considered to be found if any of them return true. The output from defining this field are: 1) the various fields and options will be added as macro constants to static.h and can be used by fw_config for probing. 2) the probe entries will result in a list of fields/options to probe that is added to the resulting struct device and handled by coreboot. BUG=b:147462631 Signed-off-by: Duncan Laurie <dlaurie@google.com> Change-Id: I8aea63e577d933aea09e0d0b09470929cc96e0de Reviewed-on: https://review.coreboot.org/c/coreboot/+/41440 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-05-16 00:39:08 +02:00
{ }
break;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 47: /* $@6: %empty */
sconfig: Add support for firmware configuration This change adds support to sconfig for generating the firmware configuration field and option definitions in devicetree.cb. In addition these fields and options can be used to probe for a device and have that device be disabled if it is not found at boot time. New tokens: fw_config: top level token, table can be defined before chips field: define field in the mask with the start and end bits option: define option in a field with the value of the field probe: indicate that a device should probe by field and option Example: fw_config field FEATURE 0 0 option DISABLE 0 option ENABLE 1 end end chip drivers/generic/feature device generic 0 on probe FEATURE ENABLE end end Variants can add new fields and add new options to existing fields in overridetree.cb but cannot redefine an existing option. Devices can have multiple probe tokens, and the device will be considered to be found if any of them return true. The output from defining this field are: 1) the various fields and options will be added as macro constants to static.h and can be used by fw_config for probing. 2) the probe entries will result in a list of fields/options to probe that is added to the resulting struct device and handled by coreboot. BUG=b:147462631 Signed-off-by: Duncan Laurie <dlaurie@google.com> Change-Id: I8aea63e577d933aea09e0d0b09470929cc96e0de Reviewed-on: https://review.coreboot.org/c/coreboot/+/41440 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-05-16 00:39:08 +02:00
{
cur_field = get_fw_config_field((yyvsp[0].string));
}
break;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 48: /* fw_config_field: FW_CONFIG_FIELD STRING $@6 fw_config_field_children END */
sconfig: Add support for firmware configuration This change adds support to sconfig for generating the firmware configuration field and option definitions in devicetree.cb. In addition these fields and options can be used to probe for a device and have that device be disabled if it is not found at boot time. New tokens: fw_config: top level token, table can be defined before chips field: define field in the mask with the start and end bits option: define option in a field with the value of the field probe: indicate that a device should probe by field and option Example: fw_config field FEATURE 0 0 option DISABLE 0 option ENABLE 1 end end chip drivers/generic/feature device generic 0 on probe FEATURE ENABLE end end Variants can add new fields and add new options to existing fields in overridetree.cb but cannot redefine an existing option. Devices can have multiple probe tokens, and the device will be considered to be found if any of them return true. The output from defining this field are: 1) the various fields and options will be added as macro constants to static.h and can be used by fw_config for probing. 2) the probe entries will result in a list of fields/options to probe that is added to the resulting struct device and handled by coreboot. BUG=b:147462631 Signed-off-by: Duncan Laurie <dlaurie@google.com> Change-Id: I8aea63e577d933aea09e0d0b09470929cc96e0de Reviewed-on: https://review.coreboot.org/c/coreboot/+/41440 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-05-16 00:39:08 +02:00
{ }
break;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 49: /* fw_config_option: FW_CONFIG_OPTION STRING NUMBER */
{ add_fw_config_option(cur_field, (yyvsp[-1].string), strtoull((yyvsp[0].string), NULL, 0)); }
sconfig: Add support for firmware configuration This change adds support to sconfig for generating the firmware configuration field and option definitions in devicetree.cb. In addition these fields and options can be used to probe for a device and have that device be disabled if it is not found at boot time. New tokens: fw_config: top level token, table can be defined before chips field: define field in the mask with the start and end bits option: define option in a field with the value of the field probe: indicate that a device should probe by field and option Example: fw_config field FEATURE 0 0 option DISABLE 0 option ENABLE 1 end end chip drivers/generic/feature device generic 0 on probe FEATURE ENABLE end end Variants can add new fields and add new options to existing fields in overridetree.cb but cannot redefine an existing option. Devices can have multiple probe tokens, and the device will be considered to be found if any of them return true. The output from defining this field are: 1) the various fields and options will be added as macro constants to static.h and can be used by fw_config for probing. 2) the probe entries will result in a list of fields/options to probe that is added to the resulting struct device and handled by coreboot. BUG=b:147462631 Signed-off-by: Duncan Laurie <dlaurie@google.com> Change-Id: I8aea63e577d933aea09e0d0b09470929cc96e0de Reviewed-on: https://review.coreboot.org/c/coreboot/+/41440 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-05-16 00:39:08 +02:00
break;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
case 50: /* fw_config_probe: FW_CONFIG_PROBE STRING STRING */
sconfig: Add support for firmware configuration This change adds support to sconfig for generating the firmware configuration field and option definitions in devicetree.cb. In addition these fields and options can be used to probe for a device and have that device be disabled if it is not found at boot time. New tokens: fw_config: top level token, table can be defined before chips field: define field in the mask with the start and end bits option: define option in a field with the value of the field probe: indicate that a device should probe by field and option Example: fw_config field FEATURE 0 0 option DISABLE 0 option ENABLE 1 end end chip drivers/generic/feature device generic 0 on probe FEATURE ENABLE end end Variants can add new fields and add new options to existing fields in overridetree.cb but cannot redefine an existing option. Devices can have multiple probe tokens, and the device will be considered to be found if any of them return true. The output from defining this field are: 1) the various fields and options will be added as macro constants to static.h and can be used by fw_config for probing. 2) the probe entries will result in a list of fields/options to probe that is added to the resulting struct device and handled by coreboot. BUG=b:147462631 Signed-off-by: Duncan Laurie <dlaurie@google.com> Change-Id: I8aea63e577d933aea09e0d0b09470929cc96e0de Reviewed-on: https://review.coreboot.org/c/coreboot/+/41440 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-05-16 00:39:08 +02:00
{ add_fw_config_probe(cur_parent, (yyvsp[-1].string), (yyvsp[0].string)); }
break;
default: break;
}
/* User semantic actions sometimes alter yychar, and that requires
that yytoken be updated with the new translation. We take the
approach of translating immediately before every use of yytoken.
One alternative is translating here after every semantic action,
but that translation would be missed if the semantic action invokes
YYABORT, YYACCEPT, or YYERROR immediately after altering yychar or
if it invokes YYBACKUP. In the case of YYABORT or YYACCEPT, an
incorrect destructor might then be invoked immediately. In the
case of YYERROR or YYBACKUP, subsequent parser actions might lead
to an incorrect destructor call or verbose syntax error message
before the lookahead is translated. */
YY_SYMBOL_PRINT ("-> $$ =", YY_CAST (yysymbol_kind_t, yyr1[yyn]), &yyval, &yyloc);
YYPOPSTACK (yylen);
yylen = 0;
*++yyvsp = yyval;
/* Now 'shift' the result of the reduction. Determine what state
that goes to, based on the state we popped back to and the rule
number reduced by. */
{
const int yylhs = yyr1[yyn] - YYNTOKENS;
const int yyi = yypgoto[yylhs] + *yyssp;
yystate = (0 <= yyi && yyi <= YYLAST && yycheck[yyi] == *yyssp
? yytable[yyi]
: yydefgoto[yylhs]);
}
goto yynewstate;
/*--------------------------------------.
| yyerrlab -- here on detecting error. |
`--------------------------------------*/
yyerrlab:
/* Make sure we have latest lookahead translation. See comments at
user semantic actions for why this is necessary. */
yytoken = yychar == YYEMPTY ? YYSYMBOL_YYEMPTY : YYTRANSLATE (yychar);
/* If not already recovering from an error, report this error. */
if (!yyerrstatus)
{
++yynerrs;
yyerror (YY_("syntax error"));
}
if (yyerrstatus == 3)
{
/* If just tried and failed to reuse lookahead token after an
error, discard it. */
if (yychar <= YYEOF)
{
/* Return failure if at end of input. */
if (yychar == YYEOF)
YYABORT;
}
else
{
yydestruct ("Error: discarding",
yytoken, &yylval);
yychar = YYEMPTY;
}
}
/* Else will try to reuse lookahead token after shifting the error
token. */
goto yyerrlab1;
/*---------------------------------------------------.
| yyerrorlab -- error raised explicitly by YYERROR. |
`---------------------------------------------------*/
yyerrorlab:
/* Pacify compilers when the user code never invokes YYERROR and the
label yyerrorlab therefore never appears in user code. */
if (0)
YYERROR;
/* Do not reclaim the symbols of the rule whose action triggered
this YYERROR. */
YYPOPSTACK (yylen);
yylen = 0;
YY_STACK_PRINT (yyss, yyssp);
yystate = *yyssp;
goto yyerrlab1;
/*-------------------------------------------------------------.
| yyerrlab1 -- common code for both syntax error and YYERROR. |
`-------------------------------------------------------------*/
yyerrlab1:
yyerrstatus = 3; /* Each real token shifted decrements this. */
/* Pop stack until we find a state that shifts the error token. */
for (;;)
{
yyn = yypact[yystate];
if (!yypact_value_is_default (yyn))
{
yyn += YYSYMBOL_YYerror;
if (0 <= yyn && yyn <= YYLAST && yycheck[yyn] == YYSYMBOL_YYerror)
{
yyn = yytable[yyn];
if (0 < yyn)
break;
}
}
/* Pop the current state because it cannot handle the error token. */
if (yyssp == yyss)
YYABORT;
yydestruct ("Error: popping",
YY_ACCESSING_SYMBOL (yystate), yyvsp);
YYPOPSTACK (1);
yystate = *yyssp;
YY_STACK_PRINT (yyss, yyssp);
}
YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN
*++yyvsp = yylval;
YY_IGNORE_MAYBE_UNINITIALIZED_END
/* Shift the error token. */
YY_SYMBOL_PRINT ("Shifting", YY_ACCESSING_SYMBOL (yyn), yyvsp, yylsp);
yystate = yyn;
goto yynewstate;
/*-------------------------------------.
| yyacceptlab -- YYACCEPT comes here. |
`-------------------------------------*/
yyacceptlab:
yyresult = 0;
goto yyreturn;
/*-----------------------------------.
| yyabortlab -- YYABORT comes here. |
`-----------------------------------*/
yyabortlab:
yyresult = 1;
goto yyreturn;
#if !defined yyoverflow
/*-------------------------------------------------.
| yyexhaustedlab -- memory exhaustion comes here. |
`-------------------------------------------------*/
yyexhaustedlab:
yyerror (YY_("memory exhausted"));
yyresult = 2;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
goto yyreturn;
#endif
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
/*-------------------------------------------------------.
| yyreturn -- parsing is finished, clean up and return. |
`-------------------------------------------------------*/
yyreturn:
if (yychar != YYEMPTY)
{
/* Make sure we have latest lookahead translation. See comments at
user semantic actions for why this is necessary. */
yytoken = YYTRANSLATE (yychar);
yydestruct ("Cleanup: discarding lookahead",
yytoken, &yylval);
}
/* Do not reclaim the symbols of the rule whose action triggered
this YYABORT or YYACCEPT. */
YYPOPSTACK (yylen);
YY_STACK_PRINT (yyss, yyssp);
while (yyssp != yyss)
{
yydestruct ("Cleanup: popping",
YY_ACCESSING_SYMBOL (+*yyssp), yyvsp);
YYPOPSTACK (1);
}
#ifndef yyoverflow
if (yyss != yyssa)
YYSTACK_FREE (yyss);
#endif
return yyresult;
}