serial: ifx6x60: Add module parameters to manage the modem status through sysfs
PATCH 1/1 serial: ifx6x60: Add module parameters to manage the modem status through sysfs
The Medfield Platform implements a recovery procedure consisting in an escalation from simple and light recovery procedures to stronger ones with increased visibility and impact to end-user.After platform find some problem from Modem,such as no response, platform will try do modem warm reset.If several tries failed, platform will try to do modem cold boot procedure.For Modem Cold Boot, AP is responsible to generate blob (binary object containing PIN code and other necessary information). Blob is stored in AP volatile memory. AP decides to read PIN code from cache instead of prompting end-user, and sends it to modem as if end-user had entered it.
This patch add module parameters to manage the modem status through sysfs. Reset_modem can be read and write by user space.When read the reset_modem,user space will get the mdm_reset_state which used to avoid to run twice at once.When set the reset_modem to IFX_COLD_RESET_REQ,modem will do cold reset, other val value will trigger modem reset.
Hangup_reasons used to give one interface to user space to know and clear the modem reset reasons. Now there are four reasons:SPI timeout, modem initiative reset,modem coredump,spi tranfer error.
--- drivers/tty/serial/Kconfig | 2 +- drivers/tty/serial/ifx6x60.c | 193 ++++++++++++++++++++++++++++++++++++++++++ drivers/tty/serial/ifx6x60.h | 8 ++ 3 files changed, 202 insertions(+), 1 deletions(-)
drivers/tty/serial/Kconfig +1 -1
@@ -1323,7 +1323,7 @@ config SERIAL_ALTERA_UART_CONSOLE config SERIAL_IFX6X60 tristate "SPI protocol driver for Infineon 6x60 modem (EXPERIMENTAL)" - depends on GPIOLIB && SPI + depends on GPIOLIB && SPI && X86_INTEL_MID && INTEL_SCU_IPC help Support for the IFX6x60 modem devices on Intel MID platforms.
drivers/tty/serial/ifx6x60.c +193 -0
229 lines not on this page · raw message
drivers/tty/serial/ifx6x60.h +8 -0
@@ -66,6 +66,13 @@#define IFX_SPI_POWER_DATA_PENDING 1#define IFX_SPI_POWER_SRDY 2 + +/* reasons for hanging up */ +#define HU_TIMEOUT 1/* spi timer out */ +#define HU_RESET 2/* modem initiative reset */ +#define HU_COREDUMP 4/* modem crash coredump */ +#define HU_RORTUR 8/* transfer error:ROR or TUR */ +struct ifx_spi_device {/* Our SPI device */ struct spi_device *spi_dev;
@@ -120,6 +127,7 @@ struct ifx_spi_device {/* modem reset */ unsigned long mdm_reset_state; +unsigned long hangup_reasons;#define MR_START 0#define MR_INPROGRESS 1#define MR_COMPLETE 2
Signature · 1 line
1.7.4.1
Greg KH
maintainerQuoted 10 lines · Jun Chen
The Medfield Platform implements a recovery procedure consisting in an escalation from simple and light recovery procedures to stronger ones with increased visibility and impact to end-user.After platform find some problem from Modem,such as no response, platform will try do modem warm reset.If several tries failed, platform will try to do modem cold boot procedure.For Modem Cold Boot, AP is responsible to generate blob (binary object containing PIN code and other necessary information). Blob is stored in AP volatile memory. AP decides to read PIN code from cache instead of prompting end-user, and sends it to modem as if end-user had entered it.
Quoted 7 lines
This patch add module parameters to manage the modem status through sysfs.
Reset_modemcan be read and write by user space.When read the reset_modem,user space will get themdm_reset_statewhich used to avoid to run twice at once.When set thereset_modemto IFX_COLD_RESET_REQ,modem will do cold reset, other val value will trigger modem reset.
Hangup_reasonsused to give one interface to user space to know and clear the modem reset reasons. Now there are four reasons:SPI timeout, modem initiative reset,modem coredump,spi tranfer error.
Why are these module parameters? Why not just "real" sysfs files instead? That way, if you have multiple devices in a system, it will work properly for them. Right now you are limited to 1 device, right?
And where have you documented these options?
thanks,
greg k-h
Quoted 16 lines · On Fri, 16 Nov 2012 04:38:06 -0800 Greg KH <[email protected]> wrote:
Quoted 15 lines · Jun Chen
The Medfield Platform implements a recovery procedure consisting in an escalation from simple and light recovery procedures to stronger ones with increased visibility and impact to end-user.After platform find some problem from Modem,such as no response, platform will try do modem warm reset.If several tries failed, platform will try to do modem cold boot procedure.For Modem Cold Boot, AP is responsible to generate blob (binary object containing PIN code and other necessary information). Blob is stored in AP volatile memory. AP decides to read PIN code from cache instead of prompting end-user, and sends it to modem as if end-user had entered it.
This patch add module parameters to manage the modem status through sysfs.
Reset_modemcan be read and write by user space.When read the reset_modem,user space will get themdm_reset_statewhich used to avoid to run twice at once.When set thereset_modemto IFX_COLD_RESET_REQ,modem will do cold reset, other val value will trigger modem reset.
Quoted 6 lines
Quoted 2 lines
Hangup_reasonsused to give one interface to user space to know and clear the modem reset reasons. Now there are four reasons:SPI timeout, modem initiative reset,modem coredump,spi tranfer error.Why are these module parameters? Why not just "real" sysfs files instead? That way, if you have multiple devices in a system, it will work properly for them. Right now you are limited to 1 device, right?
Yes and its highly unlikely that there will ever be anyone who needs two.
Alan
Greg KH
maintainerQuoted 19 lines · Alan Cox
Quoted 16 lines · On Fri, 16 Nov 2012 04:38:06 -0800 Greg KH <[email protected]> wrote:
Quoted 15 lines · Jun Chen
The Medfield Platform implements a recovery procedure consisting in an escalation from simple and light recovery procedures to stronger ones with increased visibility and impact to end-user.After platform find some problem from Modem,such as no response, platform will try do modem warm reset.If several tries failed, platform will try to do modem cold boot procedure.For Modem Cold Boot, AP is responsible to generate blob (binary object containing PIN code and other necessary information). Blob is stored in AP volatile memory. AP decides to read PIN code from cache instead of prompting end-user, and sends it to modem as if end-user had entered it.
This patch add module parameters to manage the modem status through sysfs.
Reset_modemcan be read and write by user space.When read the reset_modem,user space will get themdm_reset_statewhich used to avoid to run twice at once.When set thereset_modemto IFX_COLD_RESET_REQ,modem will do cold reset, other val value will trigger modem reset.
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
Hangup_reasonsused to give one interface to user space to know and clear the modem reset reasons. Now there are four reasons:SPI timeout, modem initiative reset,modem coredump,spi tranfer error.Why are these module parameters? Why not just "real" sysfs files instead? That way, if you have multiple devices in a system, it will work properly for them. Right now you are limited to 1 device, right?
Yes and its highly unlikely that there will ever be anyone who needs two.
Ok, but why a module parameter? That's a very "odd" way to do this type of interaction, why not just a "normal" sysfs file instead?
Either way, there's no documentation here, which is needed for a new kernel/user api that is being created. Someone needs to add an entry for Documentation/ABI/ here.
thanks,
greg k-h