On Wed, Nov 18, 2009 at 21:00, Song, Barry wrote: >From: Mike Frysinger [mailto:[email protected]] >>On Wed, Nov 18, 2009 at 02:34, Song, Barry wrote: >>> bfin5xx_spi_master.num_chipselect in its board. I maybe delete >>> MAX_GPIO_CS, and change >>> .num_chipselect = MAX_CTRL_CS + MAX_GPIO_CS, >>> To >>> .num_chipselect = MAX_CTRL_CS + MAX_BLACKFIN_GPIOS, >>> on our board. >> >> i dont know why you would do that. i dont know why you need to know >> the limit anyways ... if the cs is below MAX_CTRL_CS, then it's a >> dedicated cs. if it's not, then it's a gpio. run the setup code like >> normal and if gpio_request() fails (like it can do anyways if it's >> already taken), then the SPI master will clean up after things and >> return an error. > > I don't think it is a good way in fact. Spi core compares the devices' cs > with MAX cs of SPI master.
which really doesnt matter. the spi core does it to simplify error checking for all masters. it isnt a hard requirement as our code already falls back to gpio_request(). > To support what you said, MAX int type need be given to SPI controllers. I > don't think it makes sense. except that as soon as .cs_gpio is combined into .cs, we already have this problem and using MAX_BLACKFIN_GPIOS artificially limits it. whether we use MAX_BLACKFIN_GPIOS or ARCH_NR_GPIOS really doesnt matter in this regard. as i'm sure you've seen, the gpiolib code sets a default limit of 256 which easily fits into a u16 even after adding the # of valid hardware cs's. -mike _______________________________________________ Linux-kernel-commits mailing list [email protected] https://blackfin.uclinux.org/mailman/listinfo/linux-kernel-commits
