Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1253435 > unrolled thread

Re: [PATCH V5 1/1] usb:serial add Fintek F81532/534 driver

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH V5 1/1] usb:serial add Fintek F81532/534 driver Peter Hung <hpeter@gmail.com> - 2015-10-22 04:30 +0200
    Re: [PATCH V5 1/1] usb:serial add Fintek F81532/534 driver Johan Hovold <johan@kernel.org> - 2015-10-27 15:50 +0100

#1253435 — Re: [PATCH V5 1/1] usb:serial add Fintek F81532/534 driver

Hi Johan,

Johan Hovold 於 2015/9/14 下午 09:33 寫道:
> On Tue, Jul 21, 2015 at 09:58:19AM +0800, Peter Hung wrote:

>>        4. RS422 Mode
>>           1. The RTS mode is dont care.
>>           2. Set M2/M1/M0 as 0/0/0
>
> I don't think all gpios should be exported for these ports if they have
> special functions that the driver could control transparently (e.g. for
> SER_RS485_RTS_ON_SEND).

Surely, we can hide some setting with definitely setting like
RS232/RS485, but the settings is only apply to our evaluation board.

Some customers will use our F81532/534 with other brand transceiver IC.
The pins setting maybe changed, so we decided to separate UART & pins
settings and let the 3 output pins controllable for customer.

Could I preserve currently UART & pins setting mode ?


>> +	current_mode &= BIT(gpio_num);
>> +
>> +	mutex_unlock(&serial_priv->change_mode_mutex);
>> +	f81534_wakeup_all_port(port->serial);
>> +
>> +	return !!current_mode;
>> +}
>
> Your gpio implementation looks wrong, but let's get back to that after
> you explain how these pins are used.
>
> If they are not really general purpose pins, then this isn't the right
> interface.

The 4x3 pins is output-only mode to control transceiver, so I'm only
implement the output functions and let all input functions failed.

Could you give some advices to me if the gpiolib interface cant be
used ?

Sorry for late reply, I'm almost ready to submit v6 when clarify some
questions.

Thanks,
-- 
With Best Regards,
Peter Hung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1256803

On Thu, Oct 22, 2015 at 10:25:26AM +0800, Peter Hung wrote:
> Hi Johan,
> 
> Johan Hovold 於 2015/9/14 下午 09:33 寫道:
> > On Tue, Jul 21, 2015 at 09:58:19AM +0800, Peter Hung wrote:
> 
> >>        4. RS422 Mode
> >>           1. The RTS mode is dont care.
> >>           2. Set M2/M1/M0 as 0/0/0
> >
> > I don't think all gpios should be exported for these ports if they have
> > special functions that the driver could control transparently (e.g. for
> > SER_RS485_RTS_ON_SEND).
> 
> Surely, we can hide some setting with definitely setting like
> RS232/RS485, but the settings is only apply to our evaluation board.
> 
> Some customers will use our F81532/534 with other brand transceiver IC.
> The pins setting maybe changed, so we decided to separate UART & pins
> settings and let the 3 output pins controllable for customer.
> 
> Could I preserve currently UART & pins setting mode ?

If the pins can be set independently of the mode, and in principle be
used as general purpose output-only pins, then you should use the
gpiolib interface.

However, in the last patch it did look like the gpio-implementation was
intertwined with mode selection, something which made it seem like a bad
fit.

Would you be able to separate it, and specifically, make the gpio and
mode-handling generic and not specific for your evaluation board?

Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web