Error using blocking iterator

[michaelmarconi]

Hi, I've successfully used the streaming interface using the request method:

fn do_main(args: Cli) -> errors::Result<()> {
    let mut chip = Chip::new("/dev/gpiochip7")?;
    let lines = vec![0, 1, 2, 3, 4, 5];
    let initial_values = vec![0; lines.len()];
    loop {
        let handle = chip.get_lines(&lines)?.request(
            LineRequestFlags::INPUT,
            &initial_values,
            "multiread",
        )?;
        println!("Values: {:?}", handle.get_values()?);
        thread::sleep(time::Duration::from_millis(10));
    }
}

When I try to use a blocking iterator however (see code below), I get the following error:
Error: Error(Msg("lineevent ioctl failed"), State { next_error: Some(Sys(ENODEV)), backtrace: InternalBacktrace { backtrace: None } }).

ENODEV would appear to be a device driver issue ("the corresponding device driver does not support the ioctl() function.") but I'm not clear on that.

Has anyone bumped into this issue before?

Failing code:

fn do_main(args: Cli) -> errors::Result<()> {
    let mut chip = Chip::new("/dev/gpiochip7")?;
    let input = chip.get_line(0)?;

    // Show all state changes for this line forever
    for event in input.events(
        LineRequestFlags::INPUT,
        EventRequestFlags::BOTH_EDGES,
        "rust-gpio",
    )? {
        println!("{:?}", event?);
    }

    Ok(())
}

[posborne]

@michaelmarconi Can you run this example with strace to see the syscall that is failing? What's your kernel version?

[michaelmarconi]

Hi @posborne, thanks for responding, however we've managed to correct an issue with our custom Linux OS that was causing this.

In this case, the GPIO lines in question are implemented using Microchip MCP23017 I2C->GPIO
expander. The configuration of the device within the Linux device-tree was missing the definition of which GPIO signal on the host CPU the INTA pin from the MCP23017 was connected.

Once that was corrected, the blocking iterator started working as expected!

[posborne]

Hi @posborne, thanks for responding, however we've managed to correct an issue with our custom Linux OS that was causing this.

Thanks for the update, glad you figured out the root cause.