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

1768 lines
55 KiB
Plaintext
Raw Normal View History

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
/* A Bison parser, made by GNU Bison 3.5.3. */
/* 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. */
/* 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. */
/* Undocumented macros, especially those whose name start with YY_,
are private implementation details. Do not rely on them. */
/* Identify Bison output. */
#define YYBISON 1
/* Bison version. */
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
#define YYBISON_VERSION "3.5.3"
/* 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 */
#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
/* Enabling verbose error messages. */
#ifdef YYERROR_VERBOSE
# undef YYERROR_VERBOSE
# define YYERROR_VERBOSE 1
#else
# define YYERROR_VERBOSE 0
#endif
/* Use api.header.include to #include this header
instead of duplicating it here. */
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
#ifndef YY_YY_SRC_COREBOOT_UTIL_SCONFIG_SCONFIG_TAB_H_SHIPPED_INCLUDED
# define YY_YY_SRC_COREBOOT_UTIL_SCONFIG_SCONFIG_TAB_H_SHIPPED_INCLUDED
/* Debug traces. */
#ifndef YYDEBUG
# define YYDEBUG 0
#endif
#if YYDEBUG
extern int yydebug;
#endif
/* Token type. */
#ifndef YYTOKENTYPE
# define YYTOKENTYPE
enum yytokentype
{
CHIP = 258,
DEVICE = 259,
REGISTER = 260,
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
ALIAS = 261,
REFERENCE = 262,
ASSOCIATION = 263,
BOOL = 264,
STATUS = 265,
MANDATORY = 266,
BUS = 267,
RESOURCE = 268,
END = 269,
EQUALS = 270,
HEX = 271,
STRING = 272,
PCI = 273,
PNP = 274,
I2C = 275,
APIC = 276,
CPU_CLUSTER = 277,
CPU = 278,
DOMAIN = 279,
IRQ = 280,
DRQ = 281,
SLOT_DESC = 282,
IO = 283,
NUMBER = 284,
SUBSYSTEMID = 285,
INHERIT = 286,
IOAPIC_IRQ = 287,
IOAPIC = 288,
PCIINT = 289,
GENERIC = 290,
SPI = 291,
USB = 292,
MMIO = 293,
LPC = 294,
ESPI = 295,
FW_CONFIG_TABLE = 296,
FW_CONFIG_FIELD = 297,
FW_CONFIG_OPTION = 298,
FW_CONFIG_PROBE = 299
};
#endif
/* Value type. */
#if ! defined YYSTYPE && ! defined YYSTYPE_IS_DECLARED
union YYSTYPE
{
struct device *dev;
struct chip_instance *chip_instance;
char *string;
int number;
};
typedef union YYSTYPE YYSTYPE;
# define YYSTYPE_IS_TRIVIAL 1
# define YYSTYPE_IS_DECLARED 1
#endif
extern YYSTYPE yylval;
int yyparse (void);
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
#endif /* !YY_YY_SRC_COREBOOT_UTIL_SCONFIG_SCONFIG_TAB_H_SHIPPED_INCLUDED */
#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 || YYERROR_VERBOSE
/* 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 || YYERROR_VERBOSE */
#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. */
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
#define YYLAST 64
/* YYNTOKENS -- Number of terminals. */
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
#define YYNTOKENS 45
/* YYNNTS -- Number of nonterminals. */
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
#define YYNNTS 25
/* YYNRULES -- Number of rules. */
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
#define YYNRULES 48
/* YYNSTATES -- Number of states. */
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
#define YYNSTATES 83
#define YYUNDEFTOK 2
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
#define YYMAXUTOK 299
/* 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 ? yytranslate[YYX] : YYUNDEFTOK)
/* 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,
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
35, 36, 37, 38, 39, 40, 41, 42, 43, 44
};
#if YYDEBUG
/* YYRLINE[YYN] -- Source line where rule number YYN was defined. */
static const yytype_int8 yyrline[] =
{
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, 24, 24, 24, 24, 26, 26, 26, 26, 26,
28, 28, 28, 28, 28, 28, 28, 28, 28, 30,
30, 39, 39, 47, 49, 53, 53, 55, 58, 61,
64, 67, 70, 73, 76, 79, 83, 86, 86, 89,
89, 92, 92, 98, 98, 104, 104, 110, 114
};
#endif
#if YYDEBUG || YYERROR_VERBOSE || 0
/* YYTNAME[SYMBOL-NUM] -- String name of the symbol SYMBOL-NUM.
First, the terminals, then, starting at YYNTOKENS, nonterminals. */
static const char *const yytname[] =
{
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
"$end", "error", "$undefined", "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", "FW_CONFIG_TABLE",
"FW_CONFIG_FIELD", "FW_CONFIG_OPTION", "FW_CONFIG_PROBE", "$accept",
"devtree", "chipchildren", "devicechildren", "chip", "@1", "device",
"@2", "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", "$@3", "$@4", "$@5", "fw_config_option",
"fw_config_probe", YY_NULLPTR
};
#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,
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
295, 296, 297, 298, 299
};
# endif
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
#define YYPACT_NINF (-21)
#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[] =
{
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
-21, 3, -21, -4, -21, -21, -21, -21, -2, -21,
-21, 4, -21, 11, -20, 14, 6, 13, -21, -21,
-21, -21, -21, -1, -21, 2, 17, 26, -21, -21,
-10, 29, 21, 22, -21, -7, -21, 25, -21, 30,
10, -21, -21, -6, -21, 19, -21, -21, -21, -21,
-21, -21, -21, -3, 20, -21, 33, 23, 24, 34,
-21, -21, -21, -21, -21, -21, -21, -21, 28, 37,
27, 12, 38, 31, 40, 32, 35, -21, -21, 41,
-21, -21, -21
};
/* 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[] =
{
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
2, 0, 1, 0, 38, 3, 4, 19, 0, 9,
36, 0, 37, 0, 45, 0, 0, 0, 20, 6,
5, 8, 7, 43, 40, 0, 0, 0, 41, 40,
0, 23, 0, 0, 40, 0, 46, 0, 39, 0,
0, 29, 28, 0, 44, 0, 24, 25, 26, 21,
42, 47, 18, 0, 0, 22, 0, 0, 0, 0,
11, 10, 12, 16, 13, 14, 15, 17, 0, 0,
0, 0, 0, 0, 35, 30, 0, 48, 27, 34,
31, 32, 33
};
/* YYPGOTO[NTERM-NUM]. */
static const yytype_int8 yypgoto[] =
{
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
-21, -21, -21, -21, -8, -21, 8, -21, -21, -21,
-21, -21, 9, -21, -21, -21, -21, -21, -12, -21,
-21, -21, -21, -21, -21
};
/* YYDEFGOTO[NTERM-NUM]. */
static const yytype_int8 yydefgoto[] =
{
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
-1, 1, 13, 53, 5, 9, 20, 52, 40, 49,
62, 21, 22, 64, 65, 66, 6, 8, 30, 12,
34, 29, 24, 38, 67
};
/* 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[] =
{
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
3, 15, 16, 2, 36, 19, 3, 44, 50, 23,
54, 55, 10, 7, 3, 15, 16, 35, 17, 47,
48, 14, 43, 26, 56, 18, 25, 57, 28, 58,
27, 31, 32, 37, 33, 39, 37, 37, 41, 42,
11, 59, 45, 73, 4, 60, 76, 46, 51, 68,
69, 72, 70, 71, 74, 77, 75, 79, 82, 0,
78, 61, 63, 80, 81
};
static const yytype_int8 yycheck[] =
{
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
3, 4, 5, 0, 14, 13, 3, 14, 14, 29,
13, 14, 14, 17, 3, 4, 5, 29, 7, 9,
10, 17, 34, 17, 27, 14, 12, 30, 29, 32,
17, 29, 15, 43, 8, 6, 43, 43, 17, 17,
42, 44, 17, 15, 41, 53, 34, 17, 29, 29,
17, 17, 29, 29, 17, 17, 29, 17, 17, -1,
29, 53, 53, 31, 29
};
/* YYSTOS[STATE-NUM] -- The (internal number of the) accessing
symbol of state STATE-NUM. */
static const yytype_int8 yystos[] =
{
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, 46, 0, 3, 41, 49, 61, 17, 62, 50,
14, 42, 64, 47, 17, 4, 5, 7, 14, 49,
51, 56, 57, 29, 67, 12, 17, 17, 29, 66,
63, 29, 15, 8, 65, 63, 14, 43, 68, 6,
53, 17, 17, 63, 14, 17, 17, 9, 10, 54,
14, 29, 52, 48, 13, 14, 27, 30, 32, 44,
49, 51, 55, 57, 58, 59, 60, 69, 29, 17,
29, 29, 17, 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[] =
{
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, 45, 46, 46, 46, 47, 47, 47, 47, 47,
48, 48, 48, 48, 48, 48, 48, 48, 48, 50,
49, 52, 51, 53, 53, 54, 54, 55, 56, 57,
58, 58, 59, 60, 60, 60, 61, 62, 62, 63,
63, 65, 64, 66, 64, 67, 64, 68, 69
};
/* 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, 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
};
#define yyerrok (yyerrstatus = 0)
#define yyclearin (yychar = YYEMPTY)
#define YYEMPTY (-2)
#define YYEOF 0
#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)
/* Error token number */
#define YYTERROR 1
#define YYERRCODE 256
/* 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, Type, Value, Location) \
do { \
if (yydebug) \
{ \
YYFPRINTF (stderr, "%s ", Title); \
yy_symbol_print (stderr, \
Type, Value); \
YYFPRINTF (stderr, "\n"); \
} \
} while (0)
/*-----------------------------------.
| Print this symbol's value on YYO. |
`-----------------------------------*/
static void
yy_symbol_value_print (FILE *yyo, int yytype, YYSTYPE const * const yyvaluep)
{
FILE *yyoutput = yyo;
YYUSE (yyoutput);
if (!yyvaluep)
return;
# ifdef YYPRINT
if (yytype < YYNTOKENS)
YYPRINT (yyo, yytoknum[yytype], *yyvaluep);
# endif
YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN
YYUSE (yytype);
YY_IGNORE_MAYBE_UNINITIALIZED_END
}
/*---------------------------.
| Print this symbol on YYO. |
`---------------------------*/
static void
yy_symbol_print (FILE *yyo, int yytype, YYSTYPE const * const yyvaluep)
{
YYFPRINTF (yyo, "%s %s (",
yytype < YYNTOKENS ? "token" : "nterm", yytname[yytype]);
yy_symbol_value_print (yyo, yytype, 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,
yystos[+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)
# define YY_SYMBOL_PRINT(Title, Type, 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
#if YYERROR_VERBOSE
# ifndef yystrlen
# if defined __GLIBC__ && defined _STRING_H
# define yystrlen(S) (YY_CAST (YYPTRDIFF_T, strlen (S)))
# else
/* Return the length of YYSTR. */
static YYPTRDIFF_T
yystrlen (const char *yystr)
{
YYPTRDIFF_T yylen;
for (yylen = 0; yystr[yylen]; yylen++)
continue;
return yylen;
}
# endif
# endif
# ifndef yystpcpy
# if defined __GLIBC__ && defined _STRING_H && defined _GNU_SOURCE
# define yystpcpy stpcpy
# else
/* Copy YYSRC to YYDEST, returning the address of the terminating '\0' in
YYDEST. */
static char *
yystpcpy (char *yydest, const char *yysrc)
{
char *yyd = yydest;
const char *yys = yysrc;
while ((*yyd++ = *yys++) != '\0')
continue;
return yyd - 1;
}
# endif
# endif
# ifndef yytnamerr
/* Copy to YYRES the contents of YYSTR after stripping away unnecessary
quotes and backslashes, so that it's suitable for yyerror. The
heuristic is that double-quoting is unnecessary unless the string
contains an apostrophe, a comma, or backslash (other than
backslash-backslash). YYSTR is taken from yytname. If YYRES is
null, do not copy; instead, return the length of what the result
would have been. */
static YYPTRDIFF_T
yytnamerr (char *yyres, const char *yystr)
{
if (*yystr == '"')
{
YYPTRDIFF_T yyn = 0;
char const *yyp = yystr;
for (;;)
switch (*++yyp)
{
case '\'':
case ',':
goto do_not_strip_quotes;
case '\\':
if (*++yyp != '\\')
goto do_not_strip_quotes;
else
goto append;
append:
default:
if (yyres)
yyres[yyn] = *yyp;
yyn++;
break;
case '"':
if (yyres)
yyres[yyn] = '\0';
return yyn;
}
do_not_strip_quotes: ;
}
if (yyres)
return yystpcpy (yyres, yystr) - yyres;
else
return yystrlen (yystr);
}
# endif
/* Copy into *YYMSG, which is of size *YYMSG_ALLOC, an error message
about the unexpected token YYTOKEN for the state stack whose top is
YYSSP.
Return 0 if *YYMSG was successfully written. Return 1 if *YYMSG is
not large enough to hold the message. In that case, also set
*YYMSG_ALLOC to the required number of bytes. Return 2 if the
required number of bytes is too large to store. */
static int
yysyntax_error (YYPTRDIFF_T *yymsg_alloc, char **yymsg,
yy_state_t *yyssp, int yytoken)
{
enum { YYERROR_VERBOSE_ARGS_MAXIMUM = 5 };
/* Internationalized format string. */
const char *yyformat = YY_NULLPTR;
/* Arguments of yyformat: reported tokens (one for the "unexpected",
one per "expected"). */
char const *yyarg[YYERROR_VERBOSE_ARGS_MAXIMUM];
/* Actual size of YYARG. */
int yycount = 0;
/* Cumulated lengths of YYARG. */
YYPTRDIFF_T yysize = 0;
/* There are many possibilities here to consider:
- If this state is a consistent state with a default action, then
the only way this function was invoked is if the default action
is an error action. In that case, don't check for expected
tokens because there are none.
- The only way there can be no lookahead present (in yychar) is if
this state is a consistent state with a default action. Thus,
detecting the absence of a lookahead is sufficient to determine
that there is no unexpected or expected token to report. In that
case, just report a simple "syntax error".
- Don't assume there isn't a lookahead just because this state is a
consistent state with a default action. There might have been a
previous inconsistent state, consistent state with a non-default
action, or user semantic action that manipulated yychar.
- Of course, the expected token list depends on states to have
correct lookahead information, and it depends on the parser not
to perform extra reductions after fetching a lookahead from the
scanner and before detecting a syntax error. Thus, state merging
(from LALR or IELR) and default reductions corrupt the expected
token list. However, the list is correct for canonical LR with
one exception: it will still contain any token that will not be
accepted due to an error action in a later state.
*/
if (yytoken != YYEMPTY)
{
int yyn = yypact[+*yyssp];
YYPTRDIFF_T yysize0 = yytnamerr (YY_NULLPTR, yytname[yytoken]);
yysize = yysize0;
yyarg[yycount++] = yytname[yytoken];
if (!yypact_value_is_default (yyn))
{
/* Start YYX at -YYN if negative to avoid negative indexes in
YYCHECK. In other words, skip the first -YYN actions for
this state because they are default actions. */
int yyxbegin = yyn < 0 ? -yyn : 0;
/* Stay within bounds of both yycheck and yytname. */
int yychecklim = YYLAST - yyn + 1;
int yyxend = yychecklim < YYNTOKENS ? yychecklim : YYNTOKENS;
int yyx;
for (yyx = yyxbegin; yyx < yyxend; ++yyx)
if (yycheck[yyx + yyn] == yyx && yyx != YYTERROR
&& !yytable_value_is_error (yytable[yyx + yyn]))
{
if (yycount == YYERROR_VERBOSE_ARGS_MAXIMUM)
{
yycount = 1;
yysize = yysize0;
break;
}
yyarg[yycount++] = yytname[yyx];
{
YYPTRDIFF_T yysize1
= yysize + yytnamerr (YY_NULLPTR, yytname[yyx]);
if (yysize <= yysize1 && yysize1 <= YYSTACK_ALLOC_MAXIMUM)
yysize = yysize1;
else
return 2;
}
}
}
}
switch (yycount)
{
# define YYCASE_(N, S) \
case N: \
yyformat = S; \
break
default: /* Avoid compiler warnings. */
YYCASE_(0, YY_("syntax error"));
YYCASE_(1, YY_("syntax error, unexpected %s"));
YYCASE_(2, YY_("syntax error, unexpected %s, expecting %s"));
YYCASE_(3, YY_("syntax error, unexpected %s, expecting %s or %s"));
YYCASE_(4, YY_("syntax error, unexpected %s, expecting %s or %s or %s"));
YYCASE_(5, YY_("syntax error, unexpected %s, expecting %s or %s or %s or %s"));
# undef YYCASE_
}
{
/* Don't count the "%s"s in the final size, but reserve room for
the terminator. */
YYPTRDIFF_T yysize1 = yysize + (yystrlen (yyformat) - 2 * yycount) + 1;
if (yysize <= yysize1 && yysize1 <= YYSTACK_ALLOC_MAXIMUM)
yysize = yysize1;
else
return 2;
}
if (*yymsg_alloc < yysize)
{
*yymsg_alloc = 2 * yysize;
if (! (yysize <= *yymsg_alloc
&& *yymsg_alloc <= YYSTACK_ALLOC_MAXIMUM))
*yymsg_alloc = YYSTACK_ALLOC_MAXIMUM;
return 1;
}
/* Avoid sprintf, as that infringes on the user's name space.
Don't have undefined behavior even if the translation
produced a string with the wrong number of "%s"s. */
{
char *yyp = *yymsg;
int yyi = 0;
while ((*yyp = *yyformat) != '\0')
if (*yyp == '%' && yyformat[1] == 's' && yyi < yycount)
{
yyp += yytnamerr (yyp, yyarg[yyi++]);
yyformat += 2;
}
else
{
++yyp;
++yyformat;
}
}
return 0;
}
#endif /* YYERROR_VERBOSE */
/*-----------------------------------------------.
| Release the memory associated to this symbol. |
`-----------------------------------------------*/
static void
yydestruct (const char *yymsg, int yytype, YYSTYPE *yyvaluep)
{
YYUSE (yyvaluep);
if (!yymsg)
yymsg = "Deleting";
YY_SYMBOL_PRINT (yymsg, yytype, yyvaluep, yylocationp);
YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN
YYUSE (yytype);
YY_IGNORE_MAYBE_UNINITIALIZED_END
}
/* The lookahead symbol. */
int yychar;
/* The semantic value of the lookahead symbol. */
YYSTYPE yylval;
/* Number of syntax errors so far. */
int yynerrs;
/*----------.
| yyparse. |
`----------*/
int
yyparse (void)
{
yy_state_fast_t yystate;
/* Number of tokens to shift before error messages enabled. */
int yyerrstatus;
/* The stacks and their tools:
'yyss': related to states.
'yyvs': related to semantic values.
Refer to the stacks through separate pointers, to allow yyoverflow
to reallocate them elsewhere. */
/* The state stack. */
yy_state_t yyssa[YYINITDEPTH];
yy_state_t *yyss;
yy_state_t *yyssp;
/* The semantic value stack. */
YYSTYPE yyvsa[YYINITDEPTH];
YYSTYPE *yyvs;
YYSTYPE *yyvsp;
YYPTRDIFF_T yystacksize;
int yyn;
int yyresult;
/* Lookahead token as an internal (translated) token number. */
int yytoken = 0;
/* The variables used to return semantic value and location from the
action routines. */
YYSTYPE yyval;
#if YYERROR_VERBOSE
/* Buffer for error messages, and its allocated size. */
char yymsgbuf[128];
char *yymsg = yymsgbuf;
YYPTRDIFF_T yymsg_alloc = sizeof yymsgbuf;
#endif
#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;
yyssp = yyss = yyssa;
yyvsp = yyvs = yyvsa;
yystacksize = YYINITDEPTH;
YYDPRINTF ((stderr, "Starting parse\n"));
yystate = 0;
yyerrstatus = 0;
yynerrs = 0;
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
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 YYEMPTY or YYEOF or a valid lookahead symbol. */
if (yychar == YYEMPTY)
{
YYDPRINTF ((stderr, "Reading a token: "));
yychar = yylex ();
}
if (yychar <= YYEOF)
{
yychar = yytoken = YYEOF;
YYDPRINTF ((stderr, "Now at end of input.\n"));
}
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)
{
case 2:
{ cur_parent = root_parent; }
break;
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
case 19:
{
(yyval.chip_instance) = new_chip_instance((yyvsp[0].string));
chip_enqueue_tail(cur_chip_instance);
cur_chip_instance = (yyval.chip_instance);
}
break;
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
case 20:
{
cur_chip_instance = chip_dequeue_tail();
}
break;
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
case 21:
{
(yyval.dev) = new_device(cur_parent, cur_chip_instance, (yyvsp[-3].number), (yyvsp[-2].string), (yyvsp[-1].string), (yyvsp[0].number));
cur_parent = (yyval.dev)->last_bus;
}
break;
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
case 22:
{
cur_parent = (yyvsp[-2].dev)->parent;
}
break;
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
case 23:
{
(yyval.string) = NULL;
}
break;
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
case 24:
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;
case 27:
{ add_resource(cur_parent, (yyvsp[-3].number), strtol((yyvsp[-2].string), NULL, 0), strtol((yyvsp[0].string), NULL, 0)); }
break;
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
case 28:
{ add_reference(cur_chip_instance, (yyvsp[0].string), (yyvsp[-2].string)); }
break;
case 29:
{ add_register(cur_chip_instance, (yyvsp[-2].string), (yyvsp[0].string)); }
break;
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
case 30:
{ add_pci_subsystem_ids(cur_parent, strtol((yyvsp[-1].string), NULL, 16), strtol((yyvsp[0].string), NULL, 16), 0); }
break;
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
case 31:
{ add_pci_subsystem_ids(cur_parent, strtol((yyvsp[-2].string), NULL, 16), strtol((yyvsp[-1].string), NULL, 16), 1); }
break;
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
case 32:
{ add_ioapic_info(cur_parent, strtol((yyvsp[-2].string), NULL, 16), (yyvsp[-1].string), strtol((yyvsp[0].string), NULL, 16)); }
break;
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
case 33:
{ add_slot_desc(cur_parent, (yyvsp[-3].string), (yyvsp[-2].string), (yyvsp[-1].string), (yyvsp[0].string)); }
break;
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
case 34:
{ add_slot_desc(cur_parent, (yyvsp[-2].string), (yyvsp[-1].string), (yyvsp[0].string), NULL); }
break;
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
case 35:
{ add_slot_desc(cur_parent, (yyvsp[-1].string), (yyvsp[0].string), NULL, NULL); }
break;
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
case 36:
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;
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
case 41:
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;
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
case 42:
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;
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
case 43:
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;
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
case 44:
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;
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
case 45:
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;
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
case 46:
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;
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
case 47:
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_option(cur_field, (yyvsp[-1].string), strtoul((yyvsp[0].string), NULL, 0)); }
break;
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
case 48:
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 ("-> $$ =", yyr1[yyn], &yyval, &yyloc);
YYPOPSTACK (yylen);
yylen = 0;
YY_STACK_PRINT (yyss, yyssp);
*++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 ? YYEMPTY : YYTRANSLATE (yychar);
/* If not already recovering from an error, report this error. */
if (!yyerrstatus)
{
++yynerrs;
#if ! YYERROR_VERBOSE
yyerror (YY_("syntax error"));
#else
# define YYSYNTAX_ERROR yysyntax_error (&yymsg_alloc, &yymsg, \
yyssp, yytoken)
{
char const *yymsgp = YY_("syntax error");
int yysyntax_error_status;
yysyntax_error_status = YYSYNTAX_ERROR;
if (yysyntax_error_status == 0)
yymsgp = yymsg;
else if (yysyntax_error_status == 1)
{
if (yymsg != yymsgbuf)
YYSTACK_FREE (yymsg);
yymsg = YY_CAST (char *, YYSTACK_ALLOC (YY_CAST (YYSIZE_T, yymsg_alloc)));
if (!yymsg)
{
yymsg = yymsgbuf;
yymsg_alloc = sizeof yymsgbuf;
yysyntax_error_status = 2;
}
else
{
yysyntax_error_status = YYSYNTAX_ERROR;
yymsgp = yymsg;
}
}
yyerror (yymsgp);
if (yysyntax_error_status == 2)
goto yyexhaustedlab;
}
# undef YYSYNTAX_ERROR
#endif
}
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. */
for (;;)
{
yyn = yypact[yystate];
if (!yypact_value_is_default (yyn))
{
yyn += YYTERROR;
if (0 <= yyn && yyn <= YYLAST && yycheck[yyn] == YYTERROR)
{
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",
yystos[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", yystos[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 || YYERROR_VERBOSE
/*-------------------------------------------------.
| yyexhaustedlab -- memory exhaustion comes here. |
`-------------------------------------------------*/
yyexhaustedlab:
yyerror (YY_("memory exhausted"));
yyresult = 2;
/* Fall through. */
#endif
/*-----------------------------------------------------.
| yyreturn -- parsing is finished, return the result. |
`-----------------------------------------------------*/
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",
yystos[+*yyssp], yyvsp);
YYPOPSTACK (1);
}
#ifndef yyoverflow
if (yyss != yyssa)
YYSTACK_FREE (yyss);
#endif
#if YYERROR_VERBOSE
if (yymsg != yymsgbuf)
YYSTACK_FREE (yymsg);
#endif
return yyresult;
}