I realized that it's a product of token. Then, I suggest that implementing time extension correctly, if some operation doesn't finish in BWT (block waiting time).

Thanks for clarification.
However, CCID_CMD_TIMEOUT should be then based on BWT value reported by the card/reader, as bulk_in() function will still timeout if BWT is longer than 5 seconds.

I see your point (I am also the one who implements reader/token). That's reasonable argument.

Let me explain, or... excuse.
The internal CCID driver was started to be written around 2003, when key size was shorter and packet was shorter, but implementations were not mature. I think that behavior based on the value by card/token implementations was not wise (probably, at that time), because the value in ATR might be questionable.

If we do, BWT time specified by ATR affects (mostly all) USB communication between the driver and card/token. It means that when it's 5 seconds, timeout error cannot be detected until 5 seconds.

Workaround for card/token is, (with current CCID driver) to reply back time extension request with bigger BWI value.

See T4654: Gemalto Ezio Shield (CT710): CCID command failed: Parameter error at offset 7, I also explain the background.